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I.  THE  NEW  MARITIME  STRATEGY 


The  illiterate  of  the  21st  century  will  not  be  those  who  cannot  read  and 
write,  but  those  who  cannot  learn,  unlearn,  and  relearn. 

Alvin  Toffler 


A,  INTRODUCTION 

A  new  maritime  strategy  was  released  in  October  2007.  Entitled  “A  Cooperative 
Strategy  for  2E*  Century  Sea  Power,”  this  document  strikes  a  balance  between  traditional 
war  fighting  tasks  and  the  historic  maritime  missions  of  deterring  war,  maintaining 
freedom  of  the  seas,  and  developing  partnerships  for  collective  seaborne  security  (Allen, 
Conway  and  Roughead,  2007).  The  strategy  acknowledges  the  unique  role  that  forces 
afloat  play  in  the  execution  of  national  power,  regardless  of  whether  that  power  is  defined 
in  political,  economic  or  military  terms.  The  document  also  represents  an  historic  first  in 
that  it  is  co-signed  by  the  Commandants  of  the  Marine  Corps,  the  Coast  Guard  and  the 
Chief  of  Naval  Operations. 

Admiral  Roughhead,  the  new  CNO,  highlighted  examples  of  the  practical 
execution  of  this  strategy  in  an  early  December  report  to  navy  leadership  called 
Rhumblines.  On  the  66**'  anniversary  of  the  attack  on  Pearl  Harbor,  in  addition  to  being 
engaged  in  combat  related  operations,  the  Navy  and  Marine  Corps  were  concurrently 
assisting  typhoon  victims  in  Bangladesh,  protecting  international  commerce  from  pirates 
off  the  Somali  coast  and  engaging  in  maritime  exercises  with  the  navies  of  Gabon, 
Cameroon  and  the  Ivory  Coast  (Roughead,  2007). 

This  strategy  forces  the  Navy  to  reevaluate  assumptions  about  DoDs’  emerging 
net-centric  capabilities  in  a  context  that  stretches  and  potentially  redefines  the  boundaries 
of  the  naval  enterprise.  These  missions  create  data  sharing  opportunities  and  challenges 
that  drive  new  requirements  and  test  the  agility  of  the  Navy’s  enterprise  architecture. 
This  thesis  describes  the  technical  underpinnings  of  the  net-centric  data  strategy, 
articulates  the  emerging  role  of  Communities  of  Interest  (COI)  in  the  context  of  the  new 
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maritime  strategy,  and  provides  reeommendations  for  institutionalizing  these  concepts  so 
that  cyber  power  can  more  effectively  support  sea  power. 


B,  BACKGROUND 

Ten  years  ago,  Albers,  Garstka,  and  Stein  examined  the  gentrification  of  the 
internet,  the  availability  of  low  cost  PCs  and  the  emergence  of  the  World  Wide  Web  in 
the  context  of  military  mission  areas.  They  postulated  that  these  trends  would  create  a 
unique  operational  environment  and  enable  combat  capabilities  that  were  previously 
unachievable.  The  concept  was  dubbed  “Network  Centric  Warfare”  (Albers,  Gartska  and 
Stein,  1999).  Encouraged  by  the  initial  commercial  success  of  the  dotcom  industry,  the 
Joint  Chiefs  of  Staff  incorporated  this  eCombat  concept  into  their  strategy  and  initiated  a 
comprehensive  re-architecting  and  modernization  effort  termed  “transformation.” 

Chronologically  bracketing  the  release  of  “Network  Centric  Warfare,”  Joint 
Vision  2010  and  Joint  Vision  2020  provided  a  strategic  plan  and  end-state  for  creating  a 
modernized  force  whose  reach  and  lethality  was  improved  through  the  access  and  use  of 
information.  Published  in  1995  and  2000  respectively,  these  documents  reflected  both 
the  uncertainties  of  the  post-Cold  War  world  and  the  nascent  opportunities  of  the 
information  age.  Arguably  the  most  compelling  aspect  of  these  two  visions  was  that  they 
appropriately  estimated  the  time  it  would  take  DoD  to  transform.  In  the  context  of  the 
two  Joint  Vision  documents,  transformation  spans  a  full  25  years,  from  1995  to  2020. 

Looking  back,  even  though  we  had  good  conceptual  foresight,  we  can  see  that 
DoD  and  commercial  industry  were  on  the  bleeding  edge  of  many  information  age 
technologies  at  the  turn  of  the  2E‘  century.  It  has  taken  a  decade  of  technological  merger, 
standardization  and  experimentation  to  make  the  Net-Centric  Warfare  vision  a  feasible, 
cost-effective  option.  The  convergence  of  packet  switching,  wide-hand  and  wireless 
networking.  Service  Oriented  Architectural  patterns,  XML-based  data  exchanges,  and 
new  data  modeling  standards;  now  provide  the  technical  prerequisites  for  broad 
deployment  that  will  contribute  to  the  faster  analytical  cycles,  better  decision  making  and 
improved  operational  agility  that  was  described  in  network  centric  theory. 
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c. 


DECISION  MAKING 


Capability  is  not  achieved  by  teehnology  eonvergenee  alone.  It  appears  to  be 
based  on  a  non-linear  technology  adoption  curve.  Onee  teehnologieal  maturity  is 
reaehed,  adoption  ean  be  stimulated  by  external  environmental  interventions  (warfare), 
doctrinal  and  organizational  changes  and  ultimately,  human  learning.  Episodic  or 
punctuated  adjustments  can  radically  improve  capability,  e.g.,  cruise  missiles  and  UAVs. 
Adoption  is  also  a  function  of  resources.  DoD  may  now  be  in  a  phase  of  modernization 
where  it  is  more  costly  to  stagnate  and  maintain  legacy  infrastructure  than  it  is  to  invest  in 
new  teehnologies.  Malcolm  Gladwell  defined  a  tipping  point  or  “level  at  whieh  the 
momentum  for  ehange  becomes  unstoppable”  (Gladwell,  2000).  Change  gurus  eeho  the 
same  belief  that  transformation  -  onee  begun  -  takes  on  an  unstoppable  life  of  its  own. 
This  thesis  addresses  the  ongoing  transformation  of  data  management  in  a  net-eentric 
environment.  Teehnologieal  tipping  momentarily  aside,  one  question  is,  how  to  move 
forward  and  lean  into  adoption. 

D.  SUPERIOR  DECISIONS 

One  of  the  philosophical  underpinnings  of  IT  enabled  eommunieations  eenters 
around  the  term  interoperability.  IEEE  defines  interoperability  as  “the  ability  of  two  or 
more  systems  or  components  to  exehange  information  and  to  use  the  information  that  has 
been  exchanged”  (IEEE  90,  1990).  Colloquially,  systems  interoperability  is  understood 
to  mean  that  systems  can  talk  to  each  another.  Early  network  centrie  theory  proposed 
that  more  information  eontributed  to  better  deeision  making,  and  that  better  deeision 
making  won  wars.  It  spawned  the  coneept  of  “Post  Before  Processing”  and  eneouraged 
an  unfdtered,  high  volume  approaeh  to  deeision  support.  The  logic  and  allure  of 
interoperability  therefore,  is  that  information  sharing  in  and  of  itself,  is  a  key  enabler  of 
mission  accomplishment  and  battlefield  vietory.  This  is  not  neeessarily  so. 

Information  Superiority  is  defined  by  JV  2010  as  “the  capability  to  collect, 

process,  and  disseminate  an  uninterrupted  flow  of  information  while  exploiting  or 

denying  an  adversary’s  ability  to  do  the  same”  (Shalikashvili,  1995).  It  indieated 

Information  Superiority  was  one  of  the  key  tenets  for  operational  sueeess.  However,  the 
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subsequent  Chairman  of  the  Joint  Chiefs  of  Staff,  General  Shelton,  inchoated  in  Joint 
Vision  2020  that  information  superiority  is  insuffioient  and  that  the  true  objeotive  is 
decision  superiority.  “Decision  superiority  does  not  automatically  result  from 
information  superiority.  Information  superiority  provides  the  joint  force  a  competitive 
advantage  only  when  it  is  effectively  translated  into  superior  knowledge  and  decisions” 
(Shelton,  2000). 

This  change  in  focus  from  information  to  decision  superiority  represented  a 
tectonic  shift  that  was  intended  to  have  a  direct  effect  on  the  requirements  levied  on  the 
Navy’s  enterprise  architecture,  investment  strategy  and  procedures.  An  enterprise 
architecture  tailored  for  decision  making  is  much  more  sophisticated  than  that  needed  for 
mere  information  sharing.  Information  superiority  is  connectivity-centric.  Decision 
superiority  is  knowledge-centric.  Information  superiority,  connectivity-centric 
investment  strategies  stress  radios,  fiber,  systems  interoperability  and  networked  nodes 
with  requirements  defined  primarily  in  terms  of  bandwidth.  A  decision-superiority, 
knowledge-centric  investment  strategy  stresses  reasoning,  analytics,  decision  criteria  and 
business  processes  with  requirements  defined  primarily  in  terms  of  data  qualities 
(Kantner,  2001). 

Connectivity  and  adequate  bandwidth  are  generally  accepted  components  needed 
for  decision  superiority  strategy  and  execution.  However,  a  preoccupation  with 
bandwidth  may  have  perpetuated  sloppiness  and  inefficiency  on  the  part  of  data 
producers,  application  developers  and  users.  Requirements  that  cite  lack  of  bandwidth, 
or  the  perceived  need  for  ever  increasing  bandwidth,  may  contribute  to  a  chronic 
condition  of  information  overload  and  an  unhealthy  degree  of  data  obesity.  Investment 
decisions  and  enterprise  level  dialog  that  continually  stress  bandwidth  may  also  limit 
needed  discussion  on  efficiencies,  cost  savings  and  business  process  reengineering.  DoD 
is  finding  it  fiscally  impossible  to  meet  expectations  for  bandwidth  that  satisfy  end-users 
who  are  conditioned  by  Google  type  searching  and  gigabit  access  to  the  World  Wide 
Web  (Powner,  2008).  One  conclusion  is  that  most  of  the  information  shared  over  existing 
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bandwidth  is  never  used  for  decision  making.  Because  of  information  overload,  most 
information  produced,  shared  and  stored  is  never  used  for  any  traceable  purpose  at  all 
(Patterson,  Roth,  and  Woods,  1999). 

Superior  decision  making  is  a  human  function.  Human  factors  engineer.  Dr.  Bob 
Smilie,  indicates  that  human  decision  making  can  occur  at  a  rate  of  about  70  bps 
(personal  conversation  March,  2008).  Therefore,  in  its  simplest  form,  the  single 
overarching  requirement  of  a  decision  superiority  architecture  is  to  present  data  to  a 
human  at  a  rate  of  70  bps  or  less.  This  does  not  imply  that  decision  superiority  is  not 
dependent  on  sharing  potentially  large  amounts  of  information.  It  means  that  our 
infrastructure  has  to  be  groomed  to  support  brainwidth  limitation  not  bandwidth 
availability.  It  also  means  that  organizationally  we  must  focus  on  developing  and 
managing  predefined  decision  criteria  which  drive  our  data  requirements.  Superior 
decision  making  requires  less  information  of  higher  quality  thresholds  than  is  being 
provided  to  decision  makers  today. 

E,  SUPERIOR  DECISIONS  AND  THE  DATA  LIFE  CYCLE 

A  generally  acknowledged  premise  is  that  the  Navy’s  ability  to  create  an 
affordable  information  environment  in  which  sustainable,  superior  decision  making  is  the 
norm,  will  require  more  effective  management  of  data  across  the  entire  data  life  cycle. 
This  involves  defining  a  user  need,  collecting,  moving,  storing,  securing,  sharing, 
analyzing,  understanding  and  using  data  to  make  decisions,  then  archiving  or  disposing  of 
the  data  after  it  no  longer  has  adequate  value.  By  focusing  on  the  data  needed  for 
decision  making,  the  entire  IT  infrastructure  can  be  more  effectively  groomed  to 
aggregate  and  filter  the  available  information  to  meet  decision  quality  thresholds.  A 
consecutive  series  of  superior  decisions  can  lead  to  decision  superiority,  and  when 
expanded  to  all  applicable  mission  and  business  areas,  it  can  also  save  precious  resources. 
One  view  of  the  best  way  to  manage  bandwidth  requirements  is  to  reduce  the  amount  of 
unnecessary  information  sharing,  or  noise,  on  the  network.  Similarly,  a  positive  way  to 
reduce  the  amount  of  data  is  not  to  collect  it  unless  it  can  be  traced  to  a  decision 
requirement,  including  human  (imperfect)  generated  requirements. 


5 


Since  data  incurs  both  initial  and  recurring  costs  at  each  phase  of  its  data 
lifeeycle,  a  shift  in  IT  investment  strategies  from  systems  interoperability  to  a  foeus  on 
the  decision  processes,  and  the  data  that  supports  those  deeision  proeesses,  is  warranted. 
Capability  based  POM  cyeles  have  made  some  progress  aligning  systems  to  missions 
during  budgetary  tradeoff  analysis.  However,  new  architeetural  approaehes  sueh  as 
Serviee  Oriented  Arehiteeture  (SOA)  plaee  less  emphasis  on  systems  and  permit  a  loose 
eoupling  between  data  and  the  business  logie  used  in  the  systems.  In  this  design  pattern, 
data  beeomes  a  semi-independent  element  within  the  enterprise  arehiteeture  that  requires 
additional  management.  In  both  eomplexity  and  duration,  this  is  different  from 
management  of  the  systems  that  use  the  data.  Additionally,  sinee  data  is  not  tightly 
eoupled  to  one  system  but  ean  be  used  by  many  systems,  it  ereates  a  need  to  deal  with 
data  at  a  management  level  above  individual  systems;  at  the  enterprise-level.  In  this 
paradigm,  mapping  data  to  deeisions  cyeles  and  defining  the  qualities  of  data  needed  to 
meet  the  threshold  for  decision  making  become  the  eritieal  ehallenge.  This  is  informally 
known  as  a  requirement  to  get  the  “the  right  information,  to  the  right  person,  at  the  right 
time”  (Wennegren,  2007,  p.l). 

F.  SUPERIOR  DECISIONS  AND  DATA  STRATEGY 

Common  knowledge  again  dietates  that  superior  deeision  making  requires 
management  of  data  at  the  enterprise  level,  and  management  of  data  at  the  enterprise 
level  requires  a  data  strategy.  The  DoD  Net-eentrie  Data  Strategy  eonstitutes  a  data-level 
approaeh  to  interoperability.  The  purpose  is  to  ereate  an  environment  in  whieh  all  users 
have  an  extremely  high  level  of  eonfidenee  in  the  information  arehiteeture.  It  is  designed 
to  further  operationalize  the  notion  of  “right  information,  right  person,  right  time.” 
Rationally,  this  means  that  deeision  makers  ean  define  their  needs,  aeeess  data  when  it  is 
available,  share  data  that  is  aeeessed,  and  when  it  is  shared,  have  eonfidenee  that  it  is  fit 
for  use.  The  Data  Strategy  artieulates  a  vision  with  the  implied  requirement  to  ensure  the 
quality  of  shared  data  is  good  enough  to  make  deeisions. 

Subsequent  chapters  explore  the  eoneept  of  managing  data  as  an  enterprise  asset 
throughout  its  lifecyele;  from  the  identifieation  of  the  information  need  until  data 
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disposal.  A  generic  data  lifecycle  approach  provides  a  holistic  methodology  of  viewing 
data  and  complements  the  emerging  portfolio  management  construct  for  systems 
described  in  DoDD  8115.01,  Information  Technology  Portfolio  Management.  Data 
lifecycle  management  also  provides  a  process  to  define  and  align  the  new  roles  and 
responsibilities  of  data  management  that  scale  beyond  traditional  systems  boundaries. 
Finally  a  data  lifecycle  approach  permits  various  enterprise-level  strategies  to  be 
implemented  that  optimize  the  physical  and  logical  infrastructure  and  permitting 
organizations  to  achieve  significant  efficiencies  and  cost  savings  through  specialization, 
collaboration  and  reuse. 

G.  DATA  STRATEGY  AND  COMMUNITIES  OF  INTEREST 

DoDD  8320.02,  “Data-sharing  in  a  Net-centric  DoD,”  mandates  compliance  with 
the  DoD  Net-centric  Data  Strategy  and  provides  a  conceptual  overview  and  high  level 
considerations  that  bound  the  challenges  and  opportunities  of  data  use  in  this  technical 
paradigm.  It  requires  data  producers  to  make  their  data  visible,  accessible, 
understandable  and  trusted.  These  terms  and  the  technical  implications  will  be  addressed 
in  the  following  chapters  of  this  paper.  One  of  the  most  important  aspects  of  DoD 
8320.02  is  that  it  defines  a  new  managerial  construct  that  crosses  organizational, 
procedural  and  fiscal  boundaries  termed  Communities  of  Interest  (COI)  as: 

A  collaborative  group  of  producers  and  users  who  must  exchange 
information  in  pursuit  of  their  shared  goals,  and  who  therefore  must  have  a 
shared  vocabulary  for  the  information  they  exchange 

(Department  of  Defense  [DoD]  b,  p.  2). 

Organizational  restructuring  and  procedural  changes  naturally  lag  technological 
evolution  and  COIs  fill  a  gap  created  by  the  trend  toward  managing  enterprise  portfolios 
instead  of  stand  alone  programs.  COIs  are  designed  to  exploit  opportunities  created  by 
decoupling  data  from  tightly  integrated  applications  for  enterprise  level  requirements. 
Unfortunately  Communities  of  Interest  reside  in  an  area  of  temporary  fiscal  and 
organizational  misalignment.  The  Planning  Programming,  Budgeting  and  Execution 
(PPBE),  Acquisition  and  Requirements  (JCIDS)  processes  are  geared  toward  defining, 
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resourcing,  building  and  sustaining  systems,  overseen  by  Program  Managers  and 
Program  Executive  Offices.  As  an  Enterprise  construct,  COIs  disrupt  that  paradigm. 
COIs  place  responsibility  that  was  traditionally  vested  in  the  system  builder  and  their  data 
professionals,  into  the  hands  of  the  operator  and  a  supporting  data  working  group  or 
Integrated  Product  Team. 

The  responsibilities  of  COIs  are  not  trivial  and  are  depicted  in  Eigure  1  below. 
They  imply  a  sophisticated  level  of  understanding  of  data  technologies  as  well  as  subject 
matter  expertise  in  mission  operations.  Over  the  past  18  months,  there  has  been  a 
concerted  push  by  the  DoD  Chief  Information  Officer  to  establish  pilot  implementations 
of  Communities  of  Interest  to  establish  lessons  learned  and  best  practices.  The  pilot 
implementations  appear  to  be  reducing  risk  and  address  a  number  of  factors  that  are 
complicating  implementation.  A  case  study  involving  the  COI  concept  and  lessons 
learned  will  be  described  in  greater  detail  in  subsequent  chapters. 


• 

Identify  elements  from  other  COIs  for  reuse 

• 

Define  syntax  and  semantics  for  the  COI 

• 

Define  Data  integrity  and  quality  control  processes 

• 

Identify  data  sources  of  record  (based  on  business  rules  and 

appropriate  agreements.) 

• 

Define  data  stewards  who  manage  the  data  asset 

• 

Define  data  governance 

Eigure  1-1;  Responsibilities  of  COIs  (DoDb,  2004) 


H.  RESEARCH  QUESTIONS 

This  research  addresses  several  fundamental  issues  and  concepts  relating  to  the 
implementation  of  the  net-centric  data  strategy  within  the  Navy.  The  following  chapters 
provide  explanations  and  definitions  for  the  following  concepts  and  questions  below: 
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•  What  is  a  practical  approach  to  satisfying  the  requirements  deseribed  as 
“right  information,  to  the  right  people,  at  the  right  time”? 

•  What  is  a  data  life  eycle? 

•  How  is  the  data  life  cycle  related  to  decision  cycles? 

•  How  do  we  define  and  manage  data  requirements  at  the  Enterprise  level? 

•  What  is  the  role  of  data  quality  in  a  net-centric  data  sharing  paradigm? 

•  What  are  the  roles  and  responsibilities  of  Communities  of  Interest  (COI)? 

•  How  are  Communities  of  Interest  reflected  in  policy? 

•  How  are  COIs  resoureed? 

•  What  organizational  evolution  is  required  to  ineorporate  COIs  into  Navy’s 
data  management  infrastrueture  and  mission  area  portfolios? 

•  What  is  an  example  of  Enterprise  Management  using  COIs? 

•  What  lessons  learned  ean  be  derived  from  a  COI  ease  study? 

I,  BENEFIT  OF  THE  THESIS 

This  researeh  evaluates  data  sharing  in  a  network  eentric  environment  as  it  relates 
to  enterprise  level  systems  arehitecting.  It  applies  a  system’s  engineering  lifeeycle  model 
to  enterprise  data  management  and  utilizes  a  case  study  analysis  approach  upon  which  the 
reeommendations  and  findings  are  based.  The  objectives  of  this  work  are  to  enhanee  the 
body  of  knowledge  on  Communities  of  Interest  and  net-centric  data  sharing,  analyze  the 
extent  of  successful  implementation  of  COIs,  and  reeommend  ehanges  to  policy  and 
procedures  that  represent  a  practical,  cost  effective  migration  toward  more  rapid  net- 
centric  adoption. 

J.  SCOPE  AND  METHODOLOGY 

A  thorough  review  of  the  current  literature  on  net-centric  data  sharing  was 
performed  and  a  best  practices  approach  to  enterprise  data  requirements  management  was 
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evaluated  for  its  applieability  to  the  maritime  serviees.  The  Air  Foree,  Army,  Marine 
Corps  implementation  plans  were  evaluated  for  possible  adoption  by  the  Navy  and  Coast 
Guard.  Maritime  Domain  Awareness,  existing  eommunities  of  interest,  the  Global  Data 
Synehronization  Network  and  the  Universal  Core  initiative  were  used  as  ease  studies  to 
derive  lessons  learned.  Interviews  were  eondueted  with  various  Ageney,  Serviee  and 
Joint  praetitioners  ineluding  members  on  the  staffs  of  the  Air  Foree  Chief  Information 
Offieer,  Navy  Chief  Information  Offieer,  Deputy  Chief  of  Naval  Operations  for 
Communieations  (N6),  Army  Staff,  Marine  Corps  Chief  Information  Offieer,  Assistant 
Seeretary  of  the  Navy  for  Aequisition,  Department  of  Homeland  Seeurity  Chief 
Information  Offieer,  Defense  Information  and  Systems  Ageney,  Department  of  Justiee 
Chief  Teehnology  Offieer,  and  the  Direetor  of  National  Intelligenee  to  validate 
assumptions.  Interviews  were  also  eondueted  with  working  members  of  various  COIs 
and  industry  speeialists  to  determine  the  eapabilities  and  limitations  of  a  COI  approaeh. 

K.  SUMMARY 

The  network  enabled  military  foree  envisioned  in  Joint  Vision  2020  remains  an 
overarehing  vision  and  goal,  refleeted  in  the  National  Defense  Strategy  released  June 
2008  (Gates,  2008).  Additionally,  the  Chief  of  Naval  Operation  Strategie  Studies  Group 
XXVIII  is  tasked  to  explore  one  of  the  fundamental  eoneepts  of  JV  2020,  deeision 
superiority,  as  an  element  of  eyber  power  and  determine  how  it  ean  be  more  effeetively 
implemented  to  support  the  new  maritime  strategy  (Roughead,  2007).  This  year  marks 
the  halfway  point  in  the  modernization  journey  ealled  Transformation,  and  teehnologieal 
eonvergenee  has  finally  reaehed  the  point  where  quantum  improvements  in  eapabilities 
may  be  realized.  The  maritime  strategy,  “A  Cooperative  Strategy  for  2U*  Century  Sea 
Power,”  ereates  information  sharing  opportunities  and  ehallenges  that  will  flex  and  test 
the  tenets  of  network  eentrie  warfare.  A  premise  is  that  the  Navy  must  ehallenge  its 
assumptions  regarding  information  and  data  sharing  to  foeus  less  on  volume,  and  more  on 
the  qualities  of  data  that  lead  to  superior  deeision  making.  New  arehiteetural  paradigms 
deeouple  data  and  the  systems  that  use  the  data,  ereating  a  need  for  managing  data  at  the 
enterprise  level,  and  new  requirements  for  measuring  the  value  of  data  throughout  its 
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lifecycle.  Cost  effective  implementation  of  decision  superiority  theory  can  be  achieved 
by  optimizing  each  phase  of  the  data  lifecycle  and  managing  data  through  specific 
domains  and  organizations  called  Communities  of  Interest. 
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II.  INFORMATION  SHARING  IN  SUPPORT  OF  DECISION 

SUPERIORITY 


Information  provides  the  joint  foree  a  eompetitive  advantage  only  when  it 
is  effeetively  translated  into  deeisions. 


General  Shelton  (JV  2020,  p.  13) 


A,  DATA  DISCIPLINE 

The  former  Chairman  of  the  Joint  Chiefs  of  Staff,  General  Henry  Shelton,  stated 
explieitly  the  dependeney  of  the  deeision  making  proeess  on  information  sharing  in  the 
eontext  of  military  missions.  This  direet  relationship  with  mission  sueeess  requires  an 
overarehing,  information  sharing  strategy  managed  through  inereasing  levels  of  teehnieal 
synehronization  and  human  diseipline. 

On  the  Internet  enabled,  publiely  aeeessible  sites  of  the  World  Wide  Web 
(WWW),  requirements  are  driven  by  euriosity,  marketing,  the  desire  to  be  heard,  the 
responsibility  to  inform  and  the  mere  faet  that  teehnology  permits  massive  data  sharing. 
In  this  era,  information  has  eome  to  be  viewed  as  a  freely  available  publie  good.  Seareh 
engines  like  Google®  index  massive  data  volumes  in  tenths  of  seeonds  and  add  to  the 
illusion  that  human  knowledge  is  migrating  to  the  web.  Less  than  10  years  ago,  the 
ability  to  simply  expose  data  to  a  web-based  browser  was  enough  to  ereate  a  global 
phenomenon  ealled  the  .eom  eeonomie  boom.  The  Web  ereated  a  teehnieal  veneer  of 
eredibility  for  the  data  available  in  that  medium,  although  data  were  often  of  unknown  or 
uneontrolled  quality.  The  faseination  with  data  exposure  and  sharing  eoineided  with  the 
development  of  DoD  polieies  that  ehanged  the  fundamentals  of  diseiplined  analysis  and 
deeision  making.  In  2000,  Assistant  Seeretary  of  Defense  (ASD)  for  Command,  Control, 
Communieations  and  Information  (C3I),  John  Stenbit,  direeted  all  data  produeers  to 
“post  data  before  proeessing”  in  order  to  aehieve  a  theoretieal  time  advantage  that  eould 
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hasten  the  deeision  eyele.  Unfortunately,  both  the  .com  economic  bubble  and  the 
decision  theory  that  relied  solely  on  data  creation  and  exchange  both  proved 
unsustainable  (Nordhaus,  2004  and  Powner,  2008). 

When  the  Web  is  used  for  business,  data  sharing  requirements  are  driven  by 
factors  related  to  achieving  premium  profits,  e.g.,  security,  timeliness,  accuracy,  non¬ 
repudiation  and  the  overall  demand  for  high  quality  information.  In  this  environment, 
efficiency  -  vice  volume  -  appears  to  be  paramount.  Excess,  low  quality  information 
contributes  to  clutter  and  noise  that  confuses  the  demand  signal  for  commerce.  It  clogs 
communication  arteries  and  increases  transaction  time,  can  become  a  legal  liability  in 
terms  of  displayed  personal  information,  and  adds  directly  to  costs.  At  this  point  in 
history,  the  Navy,  and  DoD  are  caught  in  the  middle  of  the  two,  sometimes  competing 
approaches  to  Internet  /  WWW  usage;  the  ability  to  share,  and  the  desire  to  be 
productive. 

The  three  primary  military  networks,  Non-Classilied  Internet  Protocol  Router 
Network  (NIPRNET),  Secret  Internet  Protocol  Router  Network  (SIPRNET)  and  Joint 
Worldwide  Intelligence  Communication  System  (JWICS),  are  constructed  and  dependent 
on  internet  standards  and  protocols,  best  practices  and  procedures  developed  from 
experience  on  the  World  Wide  Web.  Network  Centric  Warfare  is  a  practical  application 
of  these  technical  protocols  and  practices  as  they  apply  to  military  missions  and  business 
processes.  Policies  like  DoD  Directive  8320.02,  “Data  Sharing  in  a  Net-centric  DoD,” 
and  Chairman  of  Joint  Chiefs  Instruction  6212.  ID,  “Interoperability  and  Supportability 
of  Information,  Technology  and  National  Security  Systems”  direct  DoD  systems 
providers  to  migrate  to  Internet  Protocol  based  communications,  web-based  applications 
and  publish  and  subscribe  information  sharing  paradigms.  As  of  summer  2008,  migration 
is  proceeding  slowly  with  Major  Defense  Acquisition  Programs  Network  Enabled 
Command  and  Control,  Network  Centric  Enterprise  Services,  and  Distributed  Common 
Ground  Station  just  starting  to  deliver  capability  based  on  the  adoption  of  foundational 
concepts  such  as  web-services.  Services  Oriented  Architecture  (SOA)  design  patterns  and 
Enterprise  Service  Bus  technology. 
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B, 


DECISIONS  AND  DATA 


Decision  superiority  is  a  condition  in  which  humans  derive  consistently  valid 
conclusions  from  the  analysis  of  information  and  initiate  actions  that  lead  to  mission 
accomplishment  based  on  these  conclusions  (Wikipedia,  2008).  From  a  human 
perspective,  a  decision  is  a  choice  made  between  alternatives.  In  a  well  run  business  or 
military  operation,  rational  choices  are  based  on  decision  criteria.  Decision  criteria  are 
quality  attributes  that  guide  decision  makers  along  various  tradeoff  arrangements.  A 
decision  point  is  that  stage  of  a  military  mission,  business  process,  or  a  crisis  where 
alternatives  exist  and  therefore  choices  must  be  made.  A  decision  maker  is  the  person 
who  possesses  the  authority  and  responsibility  to  chose  between  alternatives  that  are 
consequential  for  mission  or  business  success. 

Although  humans  can  make  decisions  from  experience,  gut  feel  or  intuition, 
complexity  and  a  fast  changing  environment  may  overload  the  lone  decision  maker.  The 
system  design  challenge  is  to  understand  the  decision  making  context,  then  to  inject 
relevant  and  usable  information  throughout  the  process  to  assist  decision  makers.  This 
concept  is  captured  in  the  design  heuristic,  “right  information,  right  person,  and  right 
time.”  The  goal  of  information  sharing  is  to  tee  up  actionable  alternatives  from  available 
data  to  improve  decision  making. 

Data  is  defined  as  a  set  of  facts  that  can  be  used  to  draw  conclusions  (Wikipedia, 
2008).  A  fact  is  a  statement  or  an  assertion  about  something.  A  verified  fact  is 
considered  truth  (Wikipedia,  2008).  In  theory,  decision  superiority  is  enhanced  by  a 
computer’s  ability  to  manipulate  large  amounts  of  digital  factual  data,  including  those 
that  represent  true  facts,  sharing  these  true  facts  and  aggregating  them  into  alternatives. 
This  may  permit  choices  to  be  made  faster,  with  more  consistency  and  with  more 
confidence.  The  relationship  and  value  of  a  data  sharing  architecture  used  for  decision 
making  is  a  function  of:  (1)  the  ability  to  validate  facts;  and  (2)  the  degree  of  linkage 
between  facts  and  mission  or  business  tasks.  Figure  2-1  below  depicts  the  concepts  and 
actors  involved  in  a  notional  human  decision  cycle. 
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Figure  2-1 ;  Notional  Decision  Cycle 

In  combat,  decision  superiority  implies  that  a  military  commander’s  decision 
cycle  can  be  executed  faster  than  the  time  it  takes  for  the  enemy  to  react.  The  following 
scenario,  based  on  real-world  events  is  used  to  illustrate  the  basic  relationships  between 
decision  superiority,  information  sharing  and  data  quality. 

C.  DECISION  SCENARIO 

In  January  1999,  the  USS  Carl  Vinson  Battle  Group  was  operating  in  the  northern 
Arabian  Gulf  enforcing  United  Nations  sanctions  against  Iraq.  The  previous  month. 
President  Clinton  ordered  a  massive  strike,  known  as  Desert  Fox,  in  response  to  Saddam 
Hussein’s  banishment  of  the  UN  weapon’s  inspection  team.  After  Desert  Fox,  Saddam 
initiated  a  militarization  of  the  A1  Faw  peninsula  in  southern  Iraq  in  direct  violation  of 
UN  brokered  agreements  to  maintain  the  peninsula  as  a  demilitarized  zone  after  the  Gulf 
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War.  This  violation  included  movement  of  CSSC-3  Seersueker  surface-to-surfaee  eruise 
missiles  into  the  area.  With  a  range  of  25  nautieal  miles,  the  mobile  Seersuekers  could 
target  the  U.S.  and  coalition  ships  conducting  United  Nations  Maritime  Intereeption 
Operations  in  the  most  northern  patrol  areas  of  the  Gulf.  The  movement  of  the  missiles 
to  A1  Faw  was  deelared  a  hostile  act  and  Rules  of  Engagement  were  promulgated  that 
permitted  aetions  to  be  taken  to  eliminate  the  CSSC-3  from  the  peninsula.  Sinee  they 
were  mobile,  however,  their  exact  location  was  unknown. 

Data  collection  operations  were  initiated  and  taetieal  and  national  Intelligenee, 
Surveillance  and  Reeonnaissanee  (ISR)  assets  were  tasked.  Due  to  the  nature  of  this 
partieular  target,  the  only  sensor  suite  that  would  provide  the  data  of  high  enough  quality 
to  trigger  a  deeision  was  Eleetro-Optieal  or  EO.  EO  sensors  are  essentially  eameras 
(more  formally  known  as  apertures)  that  are  mounted  on  aircraft  and  are  imbedded 
payloads  on  satellites.  An  eleetro-optieal  aperture  ereates  a  data  produet  known  as  an 
image.  The  image  is  interpreted  by  intelligenee  analysts  with  a  variety  of  systems.  In 
this  ease  the  data  quality  had  to  be  enhaneed  by  mensuration,  i.e.,  eleotronieally 
measuring  the  image  to  obtain  the  3 -dimensional  geographie  eoordinates  neeessary  for 
preeision  weapon  engagement. 

E-14  Tomeat  aireraft  equipped  with  new  digital  EO  imagers  ealled  TARPS 
eondueted  independent,  daily  reeonnaissanee  flights  over  the  A1  EAW.  One  day,  due  to 
intelligenee  cuing,  an  E-14  pilot  and  navigator  were  able  to  visually  loeate  a  suspeeted 
CSSC-3  transported  ereetor  launeher  (TEE).  The  pilot  maneuvered  the  aireraft  and 
sueeessfully  eaptured  images  of  the  CSSC-3  with  a  missile  loaded  on  the  spell  (TEE)  rail. 
He  made  a  radio  voiee  report  and  returned  to  the  earrier.  Onee  within  line  of  sight  of  the 
earner,  the  image  was  transmitted  to  a  TARPS  reeeiver  and  proeessed  by  the  imagery 
interpreter  who  extracted  the  eoordinates  and  verified  that  this  was  a  CSSC-3  TEE  with 
missile.  The  Senior  Intelligenee  Officer  validated  the  finding  of  the  imagery  interpreter 
and  reported  his  findings  to  the  Admiral’s  staff.  The  image  was  also  loaded  to  the 
NIPRNET  and  sent  to  the  Admirals  staff  and  back  to  Central  Command  (CENTCOM) 
headquarters  via  email. 
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The  Admiral  received  a  briefing  from  his  principle  staff  assistants,  the  N2  (e.g., 
intelligence),  the  strike  commander  (aka  CAG)  and  the  lawyer  (aka  JAG)  who  provided 
their  perspectives  on  the  validity  of  the  data,  verified  the  ROE  and  offered  alternatives  for 
a  strike.  The  Admiral  weighed  his  options  and  made  the  decision  to  order  the  strike.  The 
strike  was  conducted  by  an  F-18A  with  a  precision  weapon.  The  pilot  reported  that 
visually  the  CSSC-3  appeared  to  be  destroyed.  The  strike  Commander  launched  another 
TARPS  mission  to  collect  a  second  image  to  collaborate  Bomb  Damage  Assessment. 
An  intelligence  analyst  verified  the  pilot’s  initial  report  through  analysis  of  the  new 
image  and  transmitted  a  report  up  the  chain  of  command.  The  Admiral  notified 
CENTCOM  who  notified  SECDEE  who  informed  the  President. 

In  this  scenario,  the  battle  group  commander  had  a  clear  need  for  information,  and 
well-defined  decision  criteria  keyed  to  previously  approved  Rules  of  Engagement.  The 
commander  was  prepared  to  make  the  decision  to  strike  the  target  when  the  information 
collected  met  the  ROE  conditions  and  quality  threshold.  In  this  entire  scenario,  there  was 
one  significant  piece  of  data  that  triggered  the  decision  cycle  and  allowed  the  Admiral  to 
achieve  decision  superiority:  the  image.  The  image  was  a  “fact”  that  could  be  validated 
as  true.  It  provided  visual  evidence  that  the  threat  had  been  located  and  was  used  to 
generate  machine  readable  coordinates  that  defined  where  the  target  was  at  a  specific 
time. 

No  other  piece  of  intelligence  information  or  set  of  information  elements  would 
have  met  the  quality  criteria  for  the  Admiral  to  make  the  decision  in  the  context  of  his 
quality  criteria  and  ROE.  If  that  information  had  not  been  available  or  if  it  had  not  been 
shared,  no  action  would  have  been  taken.  The  players  in  this  case,  from  the  Admiral,  his 
staff,  the  pilots  and  the  analysts  all  understood  the  decision  criteria.  This  allowed  them  to 
collectively  filter  out  all  other  potential  sources  of  data  that,  through  their  experience,  use 
of  Standard  Operating  Procedures  and  ROE,  they  knew  would  not  be  satisfactory. 
Although  largely  manual,  this  scenario  contains  all  the  elements  of  effective  decision 
making  and  satisfied  the  two  criteria  for  an  effective  data  sharing  architecture  stated 
above:  (1)  support  the  ability  to  validate  facts,  and  (2)  link  the  data  to  mission  or 
business  tasks. 
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This  decision  superiority  scenario  was  successful  because  of  a  high  degree  of 
discipline  in  both  planning  and  execution.  The  intellectual  capital  of  dozens  of  highly 
trained  professionals  was  brought  to  bear  on  the  problem,  the  data  qualities  and  decision 
points  were  predefined  and  the  validity  of  the  information  product  (i.e.,  the  image)  was 
known.  Due  to  the  tremendously  larger  volumes  of  data  available  to  support  decision 
making  today,  the  current  challenge  is  to  automate  portions  of  the  decision  cycle  by 
imbedding  the  data  aggregation,  filtering  and  quality  assurance  functions  into  the 
decision  cycle  so  that  the  human  staff  can  use  computers  and  the  network  for  more 
effective  decision  making. 

D,  DATA  CENTRIC  ANALYSIS:  “YOU  ARE  A  PHOTON” 

During  his  34  year  tenure  as  the  director  of  naval  nuclear  power.  Admiral  Hyman 
Rickover  required  that  all  nuclear  power  school  students  be  able  to  trace  a  molecule  of 
water  through  its  many  transformations  from  seawater,  through  the  nuclear  power  plant 
and  back  to  the  sea.  He  rightly  assumed  that  this  would  foster  a  complete  understanding 
of  the  architectural  relationships  in  what  was  essentially  a  physical  link  and  node 
network.  The  following  section  is  designed  to  foster  an  understanding  of  the  process  by 
showing  how  data  is  created,  interpreted  and  sometimes  transformed  during  a  decision 
cycle.  The  combat  scenario  from  the  previous  section  will  be  used  for  the  sake  of 
continuity. 

At  the  human  level  the  critical  information  element  that  triggered  the  decision 
cycle  and  subsequent  weapons  delivery  was  the  electro  optical  picture  or  image.  At  the 
machine  level  however,  the  physical  phenomenon  that  was  used  to  create  the  image  was  a 
photon.  A  photon  is  simply  a  particle  of  light.  The  electro-optical  sensor  on  the  Digital 
TARPS  POD  was  sensitive  to  the  wavelengths  of  light  reflected  from  the  skin  of  the 
CSSC-3  missile  and  transporter.  The  EO  sensor  counts  the  number  of  photons  and 
converts  that  into  electrical  signals.  The  electrical  signals  are  transformed  into  binary 
code  (Is  and  Os)  in  the  digitization  process.  Once  digitized,  the  information  can  be 
transmitted  on  the  network.  However  these  measurements,  or  raw  data,  are  not  human 
interpretable  and  must  be  pushed  to  processors  that  convert  the  measurements  back  into 
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various  shades  of  grey  or  eombinations  of  red,  green  and  blue,  and  that  can  be  displayed 
as  a  matrix  of  dots  of  light  known  as  pixels.  The  aggregation  of  pixels  forms  an  image 
that  is  interpretable  by  the  human  eye.  The  image  is  stored  in  some  type  of  file  format 
such  as  JPEG  or  BITMAP  where  it  can  be  presented,  manipulated,  measured  and 
analyzed.  An  analyst  does  not  analyze  pixels;  they  analyze  the  aggregated  data  product 
called  an  image. 

The  image  has  information  appended  to  it  that  describes  the  content  of  the 
pictorial  representation  in  words.  It  contains  the  name  of  the  image,  the  size,  time  taken, 
source,  or  other  properties  deemed  necessary  to  store,  reuse  and  manage  the  image  over 
time.  This  data  about  the  image  is  called  meta-data.  Meta-data  permits  effective 
management  of  the  image  throughout  its  lifecycle.  The  image  file  is  stored  in  a  folder  or 
on  some  form  of  electronic  media  such  as  hard  drive  or  disc,  a  database  or  a  webpage. 
From  it  places  of  storage,  this  “data  at  rest”  can  be  pushed  or  pulled  from  computer 
endpoints  onto  the  network. 

From  a  process  perspective,  the  measurement  of  the  photon  reflected  from  the 
missile  launcher  was  transformed  and  stored  as  a  “digital  fact”  (i.e.,  a  data  product  called 
an  image).  The  image  was  transformed  again  in  a  process  known  as  rectification. 
Rectification  placed  the  image  in  the  context  of  a  pre-defined  reference  grid  that  aligned 
the  pixels  of  the  image  with  actual  measurements  of  latitude,  longitude  and  height  above 
the  earth.  At  this  point  the  image  was  a  “validated  fact”  and  the  staff  had  a  measurable 
degree  of  confidence  that  the  conclusions  they  drew  from  analysis  of  the  image  were 
accurate.  The  conclusions  were  then  converted  into  alternative  courses  of  action  that 
were  based  on  the  Rules  of  Engagement,  availability  of  assets  and  perceived  threat.  In 
the  scenario,  the  Admiral  had  basically  three  feasible  alternatives  based  on  the  knowledge 
he  had  received  from  his  data  collection  cycle.  He  could  choose  to  attack  the  target,  he 
could  choose  not  to  attack  the  target,  or  he  could  request  additional  information.  In  this 
case,  the  information  satisfied  his  decision  criteria  and  he  made  the  decision  to  attack  the 
target  which  resulted  in  mission  success.  From  a  data  sharing  perspective,  although  the 
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details  are  different,  the  fundamental  steps  of  tasking,  collecting,  processing,  exploiting 
and  disseminating  the  information  to  support  this  decision  cycle  are  common  for  most 
decision  cycles. 

This  was  a  best  case  scenario,  however.  In  many  decision  cycles,  the  decision 
criteria  are  not  clear  and  the  existence  of  data  to  support  the  problem  may  not  exist.  If  it 
exists,  information  is  often  of  unknown  or  dubious  quality.  Analysts  may  not  be 
specialists  and  the  decision  makers  may  not  guided  by  clearly  defined  constraints  like 
ROE.  In  these  scenarios,  which  constitute  most  of  our  decision  making,  the  goal  is  to 
cost  effectively  use  data  to  increase  the  probability  of  making  decisions  that  are  mission 
effective  and  concurrently  reduce  the  risks  associated  with  making  bad  decisions. 

E.  DEFINING  THE  DECISION  CYCLE 

The  ability  of  data  to  support  consistently  effective  decision  making  is  dependent 
on  linking  the  information  to  a  mission  or  task.  If  the  objectives  of  the  task  or  mission 
outcome  are  ambiguous  or  unknown,  it  is  difficult  to  define  the  decision  cycle.  Without 
a  decision  cycle,  decision  criteria  are  difficult  to  define  and  the  timing  of  information 
collection  and  application  cannot  be  synchronized  with  the  decision  maker  requirements. 
Lack  of  a  clearly  defined  decision  cycle  confounds  systems  developers  whose  job  it  is  to 
convert  human  need  into  executable  and  repeatable  machine  processes.  Requirements 
that  drive  cost  effective  information  sharing  leading  to  mission  success  must  be  derived, 
therefore,  from  the  desired  end-state  of  the  task  (Loshin,  2007). 

The  most  recent  doctrinal  articulation  of  goal-based  planning  and  execution  is 
embodied  in  the  concept  of  Effects  Based  Operations  (EBO).  The  first  major  tenet  of 
EBO  is  Decision  Superiority,  and  it  emphasizes  “end-state  goals  first  and  then  focus  on 
the  means  available  to  achieve  those  goals”  (Wikipedia:  2008).  Goal-based  planning  and 
execution  is  also  apparent  in  the  development  of  standard  operational  mission  threads 
which  constitute  a  repeatable  chain  of  events  with  an  objective  outcome.  A  graphic 
depicting  the  major  functions  of  the  Time  Sensitive  Strike  mission  tread  is  provided  in 
Eigure  2-2. 
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Figure  2-2:  Generic  Decision  Cycle  for  Targeting  Type  Missions 

Although  developed  several  years  after  the  strike  scenario  related  earlier  in  the 
chapter,  this  diagrammatic  view  shows  that  the  fundamentals  of  the  mission  are  relatively 
stable.  This  is  important  for  training  operators,  but  more  importantly  in  the  context  of 
this  paper,  it  helps  constrain  the  data  collection  and  sharing  sub-tasks  that  will  drive  the 
decision  cycle.  The  next  chapter  discusses  the  organizational  constructs  that  are 
evolving  that  will  enable  decision  cycles  and  the  data  required  to  drive  them  to  be 
developed  and  managed  across  the  DoD  Enterprise. 
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III.  CHARACTERISTICS  OF  THE  NEW  DATA  ENVIRONMENT 


A,  NET-CENTRICITY 

Net-centricity  is  an  operational  and  technical  concept  that  implies  optimization  of 
information  assets;  effectively  governing,  exchanging,  correlating,  analyzing  and  reusing 
data  across  multiple  data  domains  to  make  decisions  and  achieve  mission  success.  Net- 
centricity  also  implies  technical  requirements  for  data-level  integration  and 
interoperability.  These  concepts  force  a  cultural  change  in  the  way  we  think  and  address 
data  usage  and  management.  The  primary  and  most  difficult  perspective  to  change  is  the 
one  relating  to  scale.  In  the  net-centric  environment,  data  must  be  managed  as  an  asset 
across  the  Enterprise. 

Enterprise  is  a  nebulous,  subjective  term.  It  tends  to  confound  planners  and 
masks  the  scope  of  information  sharing  responsibilities  and  functions.  In  a  philosophical 
sense  the  Enterprise  is  a  decentralized,  global  entity  which  is  limited  only  by  the  people, 
processes  and  technology  operating  in  it,  not  by  any  particular  organizational  construct. 
Eor  example,  the  IT  data  standards  that  DoD  is  embracing  and  building  to  are  developed 
and  approved  by  international  bodies  of  technicians,  scientists  and  users  who 
collaboratively  move  the  art  of  the  practice  forward.  World  Wide  Web  Consortium, 
OASIS,  and  the  Open  GIS  Consortium  are  just  three  examples  of  these  groups  that 
directly  affect  DoDs  data  strategy  and  its  implementation.  The  data  that  DoD  uses  comes 
from  an  ever  expanding  global  production  capacity  enhanced  by  DoD  unique  sensors, 
information  sources  and  production  processes.  Engineering  entities  spawned  from  a 
culture  of  centralized  control,  and  well  defined  responsibilities  and  accountability,  such 
as  the  one  found  in  DoD,  find  working  in  this  enterprise  disconcerting  and  difficult. 

Conformance  to  international  standards  is  just  one  aspect  of  Enterprise  behavior. 

Eigure  3.1  below  depicts  six  major  functional  areas  that  must  be  managed  to  implement  a 

consistent  strategy  across  very  large  organizations.  The  most  important  aspect  of  these 

functions  is  that  they  are  all  based  on  arbitrary  human  decisions.  This  contrasts  sharply 

with  other,  more  traditional,  technical  fields  that  are  constrained  by  immutable  physical 
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laws  or  phenomenon  (i.e.,  gravity,  speed  of  light,  magnetism,  or  human  lifespan).  Sinee 
there  are  no  external,  measurable  constraints  on  the  way  data  is  defined,  produced, 
managed  or  used,  artificial  boundaries  are  created.  These  constraints  are  formulated  as 
definitions,  rules,  protocols  and  implementation  profiles. 
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Figure  3-1 ;  Data  Strategy  at  the  Enterprise  Level  (Derived  from  Rogalski,  2007) 


The  six  categories  above  represent  a  static  snapshot  of  many  of  the  activities  that 
occur  in  an  Enterprise.  While  adequate  to  describe  what  functions  need  to  be 
accomplished,  they  are  not  sufficient  to  define  the  organization  that  is  necessary  to 
manage  the  concurrent  dynamic  processes  that  constitute  data  operations  in  a  net-centric 
environment.  One  pragmatic  conceptual  alternative  is  to  execute  the  data  strategy  within 
the  data  lifecycle  management  paradigm.  This  approach  to  information  involves  viewing 
data  as  an  asset  that  must  be  managed  from  inception  to  disposal,  similar  to  other 
products  that  DoD  creates  or  uses.  The  data  lifecycle  “begins  with  a  business  need 
for  acquiring  data.  Over  time,  this  data  loses  its  importance  and  is  accessed  less  often, 
gradually  losing  its  business  value,  and  ending  with  its  archival  or  disposal”  (Wikipedia 
2008). 

Net-centricity  promises  increased  operational  agility,  faster  decision  making  and 
improved  mission  effectiveness  (Albers  et  al,  1999).  These  capabilities  are  possible 
because  of  a  convergence  of  technologies  whose  interrelationships  must  be  appreciated  in 
the  context  of  a  data  lifecycle  construct.  The  following  paragraph  provides  a  brief 
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description  of  the  interrelationship  of  the  four  basic  technical  tenets  associated  with  DoD 
transformation.  These  tenets  represent  fundamental  changes  to  the  information 
technology  infrastructure  and  industry  best  practices  that  underpin  DoD’s  overall 
strategy. 


SOA:  Migrating  to  Services  Oriented  Architectures  for  application  development: 


In  the  past  software  applications  were  constructed  as  monolithic  blocks  consisting 
of  several  tightly  coupled  layers.  Modifications  to  any  one  of  the  layers  affected  the 
other  layers.  Fundamentally,  architectures  following  the  SOA  design  pattern  do  two 
things.  They  permit  the  creation  of  modular,  reusable  chunks  of  business  logic  (e.g., 
services)  that  can  be  orchestrated  or  choreographed  to  create  new  functionality.  SOAs 
also  decouple  the  tiers  of  application  layer  from  each  other  so  that  each  tier  can  be 
optimized.  In  a  typical  3 -tier  environment  this  would  consist  of  a  presentation,  business, 
and  data  tier.  A  graphical  depiction  of  these  concepts  is  shown  in  Figure  3.2. 
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Figure  3-2:  n-Tier  Application  Components  (Source:  SPAWAR  DESC) 


Networks  /  Transport:  Migrating  from  circuit  switched  to  packet  switched 
networking  (i.e.,  from  tactical  data  links  to  IPV4  and  IPV6  networks). 

The  major  innovation  with  networks  is  the  migration  from  circuit  switched 
networks  to  IP,  or  packet  switched,  networks.  IP  based  networking  permits  the 
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scalability,  flexibility  and  reach  of  the  Internet.  When  eoupled  with  a  Serviees  Oriented 
Arehiteeture,  it  permits  a  highly  distributed  environment  in  which  services  and  data  ean 
be  ean  be  stored  and  managed  in  multiple  loeations  and  then  pulled  and  eonfigured  to 
support  a  mission  requirement.  SOA  coupled  with  IP  networking  provides  the 
infrastructure  for  “publish  and  subseribe”  funetionality. 

Information  Assurance;  Providing  end-to-end  security  of  the  network,  and 
providing  assurance,  eonfidentiality  for  data  in  transit  and  at  rest  potentially  aeross 
multiple  seeurity  domains. 

Information  Assuranee  relates  to  maintaining  eonfidentiality,  aeeess  and  trust  of 
data  on  the  network  and  of  maintaining  the  integrity  of  the  network  itself.  It  refers  to  the 
elassifieation  domains  sueh  as  Confidential,  Seeret  and  Top  Seeret,  their  sub-eategories 
(e.g.,  Seeret  Releasable  To)  and  inereasingly,  unclassified  aeeess  eontrols.  Personally 
Identifiable  Information  (PII)  and  Controlled  But  Unelassified  (CBU)  caveats  are  some 
of  the  most  recent  categories  of  data  for  which  information  assurance  rules  are  being 
modified  and  strengthened  within  DoD. 

Data:  Making  data  visible,  aecessible  and  understandable  on  the  network  through 
meta-  tagging  with  the  XML  family  of  standards  and  posting  to  shared  spaee. 

In  traditional  aequisition  programs  and  monolithie  software  applieation 
development,  data  is  an  integral  part  of  the  system  and  tightly  eoupled  to  it.  The  syntax 
(e.g.,  strueture)  and  semanties  (e.g.,  meaning)  of  data  are  tailored  to  the  requirement  of 
that  system  the  program  manager  for  the  system  is  responsible  for  the  data  definitions  and 
flows  within  the  system.  While  the  networks  provide  eonneetivity  and  serviees  supply 
the  applieation  logie,  eapability  improvements  assoeiated  with  the  network  eentrie 
environments  are  manifest  in  the  fact  that  data  assets  ean  be  loosely  eoupled  to  other 
eomponents  of  the  infrastrueture  and  can  be  managed  dynamieally  as  a  eomponent  of 
warfighter  speeified  mission  areas.  The  eoneept  of  data  level  integration  refers  to  the 
ability  of  eomputers  to  understand  the  meaning  and  relationship  between  various  shared 
data  elements. 
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B,  INFORMATION  REQUIREMENTS 


In  the  legacy  environment,  information  exchange  requirements  and  required  data 
qualities  could  be  predicted  adequately.  Department  of  Defense  Architectural 
Framework  (DoDAF)  views  allowed  systems  developers  to  define  their  Information 
Exchange  Requirements  (lER)  which  drove  system  design.  In  the  environment  described 
above,  the  concept  of  static  information  exchange  requirements  between  nodes  in 
system’s  architecture  is  no  longer  valid  and  new  architectural  methods  are  being 
investigated  to  augment  or  modify  the  DoD  Architecture  Framework  (DoDf,  2007).  In 
fact  one  of  the  most  attractive  aspects  of  the  Services  Oriented  design  pattern  is  the 
ability  to  support  “unanticipated  users,”  those  people,  organizations  and  processes  that 
have  a  need  for  data  but  whose  need  could  not  be  predicted  by  either  producer  or 
consumer  at  system  design  time.  These  needs  arise  from  dynamic  conditions  of  real 
world  operations. 

C.  DATA  QUALITY  AND  VALUE 

The  tradeoff  between  flexibility  and  predictability  remains  a  difficult  decision  as 
DoD  evolves  into  a  net-centric  environment.  If  information  exchange  requirements  drive 
system  design  but  can  no  longer  be  predicted,  what  now  triggers  the  processes  needed  for 
development?  It  is  possible  that  a  level  of  information  readiness  can  be  defined  that 
permits  data  producers  and  infrastructure  sustainers  to  create  and  maintain  conditions 
where  high  quality  information  exists  and  can  be  invoked  upon  demand. 

During  his  long  tenure  as  the  Chief  of  Naval  Operations,  Admiral  Vem  Clark 

tasked  his  staff  to  improve  readiness  “but  not  at  any  cosf’  (Clark,  2000).  He  directed 

that  navy  missions  be  viewed  from  a  business  perspective  and  reminded  those  of  us  on 

his  staff  that  businesses  can’t  long  afford  to  be  sloppy  with  their  working  capital  or  they 

cease  to  be  viable.  Over  the  past  eight  years  the  Navy  has  adopted  many  industry 

practices  to  try  to  reduce  cost  while  maintaining  both  current  and  future  readiness.  The 

promise  of  Network  Centric  Operations  is  that  information  can  be  cost  effectively  applied 

to  decision  making  so  that  physical  assets  like  ships,  aircraft  and  humans  can  more 

effectively  execute  the  wide  variety  of  DoD  missions.  Much  time,  effort  and  funding  has 
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been  expended  on  improving  eonneetivity;  ereating  the  network  infrastrueture  that 
provides  the  capacity  to  share  information.  Five  years  ago,  DoD  policies  started  to  reflect 
the  need  to  focus  more  attention  on  managing  the  content  on  the  network  to  stem  the 
growing  problems  of  information  overload  and  chronic  bandwidth  limitations. 

These  policies,  starting  with  the  Net-centric  Data  Strategy  in  2003,  recognized 
what  industry  had  already  learned,  namely  that  the  key  to  success  was  the  ability  of 
content  providers  to  reach  end-users  through  the  infrastructure  backbone  provided  by  the 
internet  (i.e.  Internet  Service  Providers).  More  specifically,  capability  was  achieved 
through  the  ability  of  content  providers  to  add  value  in  the  context  of  the  end-user 
defined  processes.  Since  the  cost  of  managing  data  throughout  its  lifecycle  is  largely 
independent  of  the  data’s  utility,  efficiencies  must  be  gained  by  initiating  the  lifecycle 
only  for  useful  data.  Industry  uses  the  term  Master  Data  to  reflect  information  critical  to 
business  processes.  In  DoD  a  similar  concept  is  reflected  in  the  term  Authoritative  Data 
Sources  (ADS)  (SECNAV,  2005).  Authoritative  or  Master  Data  is  defined  by  quality 
attributes  which  can  be  incorporated  into  the  data  asset  as  metadata.  Each  quality  attribute 
provides  some  arbitrary  level  of  value  that  is  based  on  mission  or  business  context. 
David  Loshin  provides  a  simple  graphical  illustration  of  the  line  of  questioning  that  must 
accompany  the  designation  of  master  or  authoritative  data  in  Eigure  3.3  below. 
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Figure  3-3:  Notional  Decision  Tree  for  Data  Quality  Assessment 


Although  technology  makes  increased  operational  flexibility  possible,  defining 
authoritative  data  requires  a  great  deal  more  planning,  discipline  and  data  governance 
than  was  necessary  under  data  management  regimes  in  the  past.  DoD  uses  Technology 
Readiness  Levels  to  determine  the  maturity  of  emerging  technologies  and  the  risk 
associated  with  incorporating  these  technologies  into  a  DoD  design.  DoD  also  uses 
operational  readiness  levels  to  provide  leadership  a  metric  on  the  current  capability  of  the 
operational  forces  under  a  commander’s  control  or  authority.  If  we  are  to  treat  data  as 
an  asset,  it  is  necessary  to  create  readiness  levels  for  data  that  can  provide  a  meaningful 
level  of  risk  reduction  and  situational  awareness  for  operational  commanders. 

A  notional  Information  Readiness  Levels  matrix  is  included  Figure  3.4  below.  It 
derives  concepts  from  Joint  Publication  6.0  “Joint  Communications”  which  describes 
eight  quality  criteria  associated  with  the  value  of  data;  visible,  accessible,  understandable, 
trusted,  interoperable,  timely,  relevant,  accurate.  The  first  four  qualities  are  primarily 
technical  in  nature  and  the  last  three  are  more  operationally  focused. 
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Information 

Readiness 

Level 

Description 

1 

Visible,  Accessible,  Understandable,  Trusted,  Timely,  Relevant  and 
Accurate  Information  is  available  to  perform  this  mission. 

2 

Visible,  Accessible,  Understandable,  Trusted  information  is 
available  to  support  this  mission. 

3 

Information  is  Visible  but  it  is  not  accessible 

4 

No  information  can  be  discovered  to  support  this  mission 

Information 

Qualities 

Definitions 

Visible 

Information  is  advertised  on  the  network  (Tagged  and  registered) 

Accessible 

Stored  in  a  shared  space  on  the  network 

Understandable 

Human  and  /  or  machine  readable 

Trusted 

Relates  to  the  authority  and  security  of  data 

Interoperable 

Ability  to  exchange  information 

Timely 

Available  in  time  to  make  a  decision 

Relevant 

As  it  applies  to  a  specific  mission 

Accurate 

The  data  conveys  the  truth  at  the  required  level  of  precision 

Figure  3-4;  Notional  Information  Readiness  Levels 


D.  RISK  REDUCTION 

One  of  the  implied  assumptions  in  DoD  net-centric  theory  is  that  data  sharing  is 
inherently  good.  In  2002  the  Assistant  Secretary  of  Defense  introduced  the  concept  of 
Task,  Post,  Process  and  Use  (TPPU)  that  replaced  the  traditional  Task,  Collect,  Process, 
Exploit,  Disseminate  (TCPED)  process  model  (U.  S.  Joint  Eorces  Command,  2004).  By 
providing  a  broader  range  of  data  to  more  potential  users  earlier  in  its  lifecycle,  this  new 
process  model  was  designed  to  reduce  the  decision  cycle  and  improve  the  ROI  of  the 
information  sharing  investment.  However  in  environments  flush  with  information,  TPPU, 
without  the  appropriate  data  quality  attributes  to  provide  some  degree  of  volumetric 
filtering,  becomes  problematic.  In  a  byline  entitled  the  “The  Too-Much  Information 
Age”  SEED  magazine  editors  predicted  that  “the  sum  of  all  information  produced  in 
2008  will  likely  exceed  the  amount  of  information  generated  by  humans  in  the  past 
40,000  years”  (Bly,  2008).  The  article  goes  on  to  state  that  there  is  an  inverse 
relationship  between  the  amount  of  information  collected  and  level  of  knowledge 
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derived.  This  is  because  critical  thinking  is  required  to  turn  knowledge  into  action  and 
there  is  just  not  enough  human  time  available.  This  assertion  is  reinforced  by  Bloom’s 
Taxonomy  of  critical  thinking  depicted  below.  Knowledge  is  the  lowest  level  and  the 
foundation  for  critical  thinking.  The  taxonomy  culminates  with  Evaluation  which  is 
defined  as  “presenting  and  defending  opinions  by  making  judgments  about  information, 
validity  of  ideas  or  quality  of  work  based  on  a  set  of  criteria”  (Barton;  1997).  Evaluation 
then  becomes  the  level  at  which  consistently  good  choices  between  alternatives  can  be 
made  and  the  therefore  the  level  that  is  the  objective  end  state  and  the  focal  point  of  our 
information  technology  investment. 


Eigure  3-5;  Bloom’s  Taxonomy 

As  stated  in  Chapter  II,  to  achieve  decision  superiority,  the  information 
technology  architecture  must  be  continuously  groomed  to  aggregate,  fuse,  distill  and 
present  information  at  a  human  consumable  rate.  According  to  Wikipedia  the  field  of 
Knowledge  Management  formally  emerged  in  1995  to  respond  to  the  need  for  more 
symbiotic  relationship  between  information  management  and  information  use.  The 
Knowledge  Management  field  has  broadened  to  include  a  wide  range  of  loosely  related 
sub-disciplines  with  no  formal  definition  (Wikipedia  2008).  Knowledge  Management 
has  become  a  cliche  for  any  information  management  approach  that  improves  the 
usability  of  data  and  capturing  human  experience  with  it.  In  a  strategic  sense.  Knowledge 
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Management  is  an  attempt  to  eollect,  categorize,  store  and  reuse  a  theoretically  ever 
expanding  volume  of  facts  and  figures  contained  in  voice,  video  and  text  formats. 

When  applied  to  practical  decision  making.  Knowledge  Management  can  become 
a  reactive  tail  chase  resulting  in  an  endless  pursuit  of  new  data  to  make  the  “best”  choice. 
In  his  book  “Risk  Analysis  in  Engineering  and  Economics,”  Bilal  Ayyub  suggests  that: 

Information  abundance  does  not  necessarily  give  us  certainty.  In  fact  this 
abundance  of  information  can  sometimes  lead  to  errors  in  decision  making 
and  undesirable  outcomes  due  to  either  overwhelmingly  confusing 
situations  or  a  sense  of  overconfidence  that  leads  to  improper  use  of 
information.  (Ayyub,  p.I) 

Professor  Ayyub  suggests  that  in  an  era  of  information  abundance,  “engineers  and 
scientists  emphasize  knowledge  and  information,  and  intentionally  or  unintentionally 
brush  aside  ignorance”  (Ayyub,  p.I6).  A  focus  on  ignorance  reduction  rather  than 
knowledge  attainment  can  lead  to  efficiency.  Wikipedia  defines  ignorance  management 
colloquially  as  “discovering  what  we  need  to  know,  but  don’t.”  This  is  an  extremely 
useful  concept  for  decision  making  because  it  inherently  deals  with  risk  and  risk 
reduction.  Knowledge  management  more  appropriately  pertains  to  researcher  and  analyst 
functions  rather  than  decision  making  activities.  In  a  practical  sense,  ignorance 
management  involves  collecting  enough  data  to  reduce  risk  to  an  acceptable  level,  or 
decision  threshold.  It  involves  epistemological  concepts  such  as  uncertainty,  complexity, 
ambiguity  and  equivocality.  In  the  context  of  military  decision  making,  an  approach  to 
based  on  reducing  ignorance  appears  consistent  with  General  Colin  Powell’s  points  for 
good  leadership  where  he  recommends  “Once  you  are  in  the  40-70  percent  range  (of 
information  collected)  go  with  your  gut”  (Powell,  2008). 

Ignorance  management  implies  you  know  what  you  don’t  know.  It  also  implies 
there  are  known  qualities  for  the  data  that  you  are  trying  to  collect  and  the  decision  maker 
will  recognize  and  understand  the  data  when  it  is  presented.  In  the  ignorance 
management  paradigm,  data  collection  and  analysis  is  terminated  once  the  decision  has 
been  reached.  In  a  knowledge  management  scenario,  there  is  the  potential  to  never  reach 
a  data  collection  termination  point.  If  the  decision  thresholds  are  well  defined,  data 
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collection,  analysis,  and  use  can  focus  on  achieving  these  thresholds.  This  focus  on  the 
decision  quality  data  and  decision  thresholds  permit  the  information  architecture  to  be 
more  effectively  groomed  to  deliver  the  “right  information,  to  the  right  person  at  the  right 
time,”  and  can  help  control  the  total  cost  associated  with  information  management. 

E.  IGNORANCE  MANAGEMENT  AND  SLA 

Attainment  of  the  operational  condition  known  as  Decision  Superiority  assumes 
that  there  are  competent/rational  decision  makers  with  the  information  and  authority  and 
will  to  make  decisions.  While  there  are  many  decisions  made  based  on  experience,  in  a 
military  operation  or  complex  business  relationship,  decision  support  tools  are  often  used. 
In  the  non-net-centric  environment,  decision  support  tools  are  pre-designed  and  the 
information  interfaces  are  static.  In  a  net-centric  environment,  the  ability  to  orchestrate 
services  and  data  create  a  dynamic  tool  suite  that  is  more  tailorable  to  changing 
operational  conditions.  As  operational  conditions  change,  decision  thresholds  change, 
and  these  changes  alter  the  qualities  of  data  and  the  reliability  of  the  tool  suite  needed  by 
the  user.  One  of  the  instruments  used  by  the  telecom  industry  to  provide  various  levels 
of  performance  to  changing  conditions  or  different  operational  priorities  is  called  the 
Service  Level  Agreement  (SLA).  Wikipedia  (2008)  defines  SLA  as,  “A  formally 
negotiated  agreement  between  two  parties.”  It  is  a  contract  that  exists  between  customers 
and  their  service  provider.  It  records  the  common  understanding  about  services,  priorities, 
responsibilities,  guarantee,  collectively  known  as  the  level  of  service.  For  example,  it 
may  specify  the  levels  of  availability,  serviceability,  performance,  operation,  or  other 
attributes  of  the  service  like  billing  and  even  penalties. 

Service  Level  Agreements  pertain  traditionally  to  the  qualities  of  the  network 
itself  or  the  availability  of  the  services  (e.g.,  applications)  that  ride  on  the  network  and  are 
often  rendered  as  a  Quality  of  Service  requirement.  Sid  Frank  in  a  2006  article  entitled 
“Service  Level  Agreements  for  Data”  responded  to  a  need  by  the  financial  services 
industry  to  more  effectively  monitor  and  control  the  quality  of  data  they  were  receiving 
from  3  party  data  producers.  Mr.  Frank  indicated  that  the  SLA  for  Data  (SLA4D)  should 
include  data  quality  metrics,  formats  and  provider  quality  certificates  (Frank,  2006). 
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These  requirements  and  solutions  are  applieable  to  the  DoD  net-eentrie 
environment  as  well,  where  poor  quality  data  introdueed  into  fundamental  proeesses 
eould  also  be  eostly  or  eatastrophie  (Frank,  2006).  The  net-eentrie  paradigm  essentially 
ereates  a  elass  of  government  entities  who  serve  as  party  vendors  that  eonstitute  the 
data  produetion  eapability  for  many  mission  areas. 

The  discussion  of  data  quality  in  the  context  of  service  level  agreements  has  yet  to 
begin  in  earnest  in  DoD  and  the  concept  of  contracts  for  SLAs  between  systems,  DoD  or 
government  agencies  is  an  emerging  field  of  study.  As  the  infrastructure  matures,  more 
services  become  available  and  more  data  exposed  for  reuse,  the  problems  and  solutions 
Mr.  Frank  discusses  will  become  more  applicable.  In  parallel  to  the  infrastructure 
maturation,  a  comprehensive  dialog  on  the  concept  of  Information  Readiness  Levels  as  a 
quality  measure,  ignorance  management  as  a  risk  reduction  technique  and  SLAs  for  data 
should  be  initiated  to  support  precision  data  operations  for  decision  support. 

F.  FUNDING  THE  DATA  LIFECYCLE 

In  order  to  reduce  costs,  gain  networking  efficiencies  and  improve  mission 
success  the  fiscal  resource  bureaucracy  must  evolve  to  accommodate  the  new  more 
dynamic  requirements  that  decision  makers  will  place  on  the  IT  infrastructure.  The 
modification  to  budgeting  systems  must  address  the  de-aggregation  of  traditional  systems 
into  components  and  the  need  to  finance  layers  of  the  SOA  n-tier  environment. 

The  defense  acquisition  process  is  driven  by  mission  needs.  The  Planning 
Programming  Budgeting  and  Execution  process  is  keyed  to  respond  to  these  needs  by 
funding  programs  and  projects  whose  functionality  is  defined  in  terms  of  systems 
requirements.  In  the  DoD  acquisition  model,  systems  defined  by  these  requirements  are 
developed,  managed  and  funded  independently  from  one  another.  These  systems  are  the 
“products”  that  DoD  creates  (i.e.,  ships,  airplanes,  radios,  sensors,  missiles,  satellites, 
software  applications,  networks).  For  most  systems,  data  is  a  byproduct  of  the  successful 
execution  of  the  acquisition  process.  That  is,  the  need  for  data  creation  and  management 
is  a  consequence  of  a  system  performing  its  intended  function. 
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The  cost  of  data  is  partially  accounted  for  and  resourced  within  the  total  lifecycle 
cost  and  total  obligation  authority  of  systems  that  consume  or  produce  data.  Any  system 
that  contains  software  (i.e.,  microprocessors  and  associated  circuitry)  contains  data  and 
all  but  the  most  rudimentary  of  systems  contain  some  software.  Gas  masks  and  9mm 
pistols  fall  into  this  category.  When  the  data  that  a  system  uses  is  produced  and 
consumed  within  a  system’s  physical  boundaries,  the  cost  of  that  data  can  be  accurately 
predicted  and  resourced  from  within  the  system’s  budget.  This  can  be  thought  of  as  a 
closed  system.  However,  when  a  system  uses  data  from  another  system  or  produces  data 
for  another  system  to  consume,  the  boundaries  are  breached  and  the  cost  estimates 
relating  to  those  data  exchanges  become  harder  to  predict.  From  a  management 
standpoint,  the  responsibilities  for  the  lifecycle  costs  of  data  are  now  shared  between  the 
producing  and  consuming  nodes.  Unfortunately,  current  acquisition  theory  and  practice 
do  not  deal  effectively  with  this  fiscal  no-man’s  land.  According  GAO  Cost  Assessment 
Guide,  costs  have  proven  so  difficult  to  predict  accurately  that  integration  is  one  of  the 
main  factors  in  budgetary  shortfalls  and  cost  overruns  for  many  major  defense  programs 
(GAO,  2007). 

One  attempt  to  realign  the  resources  with  DoD’s  emerging  transformational  needs 
was  the  creation  of  Portfolio  Managers.  The  next  chapter  will  briefly  discuss  Portfolio 
Management  and  focus  on  the  organizational  changes  related  to  data  and  services 
management  in  the  portfolio  known  as  Communities  of  Interest. 
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IV.  PORTFOLIO  MANAGEMENT  AND  COMMUNITIES  OF 

INTEREST 

A,  PORTFOLIO  MANAGEMENT 

Transformation  of  the  Department  of  Defense  into  a  net-eentrie  enterprise 
required  fundamental  ehanges  to  the  information  technology  (IT)  management  paradigm. 
This  shift  is  clearly  reflected  in  DoD  Directive  8115.01,  “Information  Technology 
Portfolio  Management”  that  mandates  that  IT  investments  would  no  longer  be  managed 
and  funded  as  individual  systems  but  as  portfolios.  The  Directive  defines  a  portfolio  as 
“a  grouping  of  IT  investments  by  capability  to  accomplish  a  specific  functional  goal, 
objective  or  mission  outcome”  (DoD,  2005). 

The  Directive  defined  and  established  the  Enterprise  as  the  DoD  and  described 
roles  and  responsibilities  for  newly  designated  portfolio  managers.  The  Enterprise  was 
decomposed  into  the  following  four  mission  areas  representing  fundamental  capabilities: 
Business  Mission  Area;  Warfighter  Mission  Area;  Enterprise  Information  Environment 
Mission  Area;  and  DoD  Intelligence  Mission  Area,  e.g.,  BMA,  WMA,  EIEMA,  and 
DIMA  respectively.  Each  mission  area  lead  has  the  responsibility  to  analyze,  select, 
control  and  evaluate  systems,  programs  and  projects  within  the  portfolio  to  optimize 
capability,  limit  redundancy  and  reduce  overall  cost  to  the  government  (DoD,  2005). 

The  Directive  was  followed  one  year  later  by  DoD  Instruction  8115.02  entitled 
“Information  Technology  Portfolio  Management  Implementation.”  The  purpose  of  the 
instruction  was  to  support  changes  to  the  Joint  Capabilities  Integration  and  Development 
System  (JCIDS),  Defense  Acquisition  System,  and  the  Planning,  Programming, 
Budgeting  and  Execution  Systems  (PPBE)  that  were  also  part  of  the  DoD’s 
transformation  initiative.  The  portfolio  management  process  was  designed  to  “continue 
the  evolution  from  an  emphasis  on  individual  systems  to  overall  mission  capability” 
(DoDd,  p.  4).  Eigure  4.1  depicts  DoD  Mission  Areas  and  their  relationships  to  the  Joint 
Capability  Areas.  Initially,  the  8115  series  was  generally  viewed  as  one  more  enigmatic 
aspect  of  DoD  transformation,  however  each  Service  retained  control  of  their  funding 
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lines.  Fiscal  Year  08  Program  Objective  Memoranda  (POM)  submissions  that  were 
being  developed  were  not  evaluated  from  the  new  portfolio  perspective.  However,  by 
PR09,  Commands,  Services  and  Agencies  were  all  attempting  to  align  with  the  new 
directives.  In  the  FYIO  POM  cycle,  portfolio  managers  have  started  to  exercise 
investment  program  oversight,  including  attempting  to  gain  influence  over  the  decisions 
to  “start,  continue,  modify  or  terminate  programs”  (DoD,  p.l2). 


POD  .(Title  10) _  IC  (Title  50) 


Figure  4-1;  DoD  Mission  Areas.  (Source  CJCSI  8410.01) 

In  addition  to  supporting  execution  of  the  newly  refined  decision  support  systems 
(e.g.,  JCIDS,  DAS  and  PPBE),  portfolio  managers,  mission  area  leads  and  sub-portfolio 
authorities’  execution  have  explicit  responsibilities  for  implementing  DoD  Directive 
8320.02,  “Data  Sharing  in  a  Net-centric  Department  of  Defense.”  Specifically  the 
responsibilities  include  (1)  facilitating  information  sharing  within  and  across 
Communities  of  Interest,  (2)  Identifying  the  highest  priority  data  sharing  needs,  (3) 
designating  a  component  lead  for  COIs  and,  (4)  defining  data  strategy  implementation 
metrics. 
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B,  DATA  SHARING  AND  PORTFOLIO  MANAGEMENT 

DoDD  8320.02  states  that  data  is  “an  essential  enabler  of  network-centric  warfare 
(NCW)  and  shall  be  made  visible,  accessible,  and  understandable  to  any  potential  user  in  the 
Department  of  Defense”  (DoDb,  2004).  This  Directive  represents  one  cornerstone  of 
defense  DoD  transformation  efforts.  All  other  transformational  directives,  instructions  and 
technical  implementations,  and  arguably  the  concept  of  the  Global  Information  Grid  itself, 
are  fundamentally  dependent  on  the  ability  to  find,  move  and  correctly  interpret  data. 

DoDD  8320.02  attempts  to  address  limitations  of  data  regulation  efforts  embarked  on 
by  DoD  in  the  early  1990s  and  codified  in  DoDD  8320.1,  “DoD  Data  Administration.”  That 
policy  attempted  to  standardize  all  data  elements  across  DoD.  This  effort  led  to  the 
development  of  massive  data  models  that  relationally  organized  a  great  deal  of  DoD 
knowledge  but  could  not  be  used  effectively  for  sharing  data.  Developers  were  forced  to 
tailor  the  mega-models  to  meet  their  data  sharing  requirements  and  reduce  the  complexity  of 
implementation.  As  computer  systems  tailored  the  models  differently,  they  could  not 
exchange  data,  and  information  flows  had  to  be  augmented  through  some  form  of  translation 
or  mediation. 

The  concepts  of  visibility,  accessibility  and  understandability  were  introduced 
previously  in  Chapter  III  as  data  qualities  that  could  be  measured  or  gauged  to  define 
information  readiness  levels  in  the  context  of  operational  scenarios.  DoDD  8320.02  and  its 
associated  implementation  guide,  DoDI  8320.02,  provide  guidance  and  define  roles  and 
responsibilities  for  DoD  to  engineer  the  conditions  that  will  achieve  the  objective  operational 
state.  Engineering  here  is  used  in  its  broadest  sense  to  include  the  social,  procedural  and 
technical  aspects  of  designing,  building  and  implementing  the  net-centric  Enterprise  data 
architecture. 

C.  COMMUNITIES  OF  INTEREST 

Communities  of  Interest  (COI)  have  emerged  at  the  heart  of  net-centric  data 
strategy.  They  represent  a  fundamental  shift  from  localized  data  management,  to  a  wider 
infusion  of  roles  and  responsibilities  focused  on  governance.  Communities  of  Interest  are 
defined  as: 
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Collaborative  groups  of  users  who  must  exehange  information  in  pursuit 
of  their  shared  goals,  interests,  missions,  or  business  proeesses  and  who 
therefore  must  have  shared  voeabulary  for  the  information  they  exehange 
(DoDb,  p.4). 

COIs  are  designed  to  reduee  the  standardization  dilemma  by  breaking  DoD  into 
smaller  data  domains  that  ean  be  managed  by  the  mission  areas  or  portfolio  managers. 
The  eoneept  has  matured  sporadieally  over  the  five  years  sinee  they  were  initially  defined 
in  the  DoD  Net-eentrie  Data  Strategy  but  their  importanee  has  eontinued  to  grow  at  a 
steady  paee  as  the  Department  evolves  its  infrastrueture  toward  web-based  paradigms. 

A  number  of  faetors  have  eontributed  to  the  modest  rate  in  whieh  COIs  have  been 
embraeed.  First,  there  appears  to  be  a  laek  of  understanding  of  the  basie  eoneepts  and 
funetions  that  COIs  are  designed  to  perform.  COIs  migrate  key  data  engineering 
responsibilities  away  from  the  aequisition  eommunity  toward  the  business  user  and 
operational  mission  praetitioner.  End  users  are  being  exposed  to  data  management 
prineiples  that  they  previously  took  for  granted  and  had  dealt  with  as  “blaek  boxes” 
within  the  Information  Teehnology  realm.  Day-to-day  experienees  with  Google  and 
other  teehnologies  that  have  faeades  of  simplieity  probably  eontribute  to  a  pervasive 
misunderstanding  of  the  eomplexity  of  harmonizing  heterogeneous  datasets. 

Seeondly,  COIs  reside  in  a  fiseal  no-man’s  land.  COI  produets  and  aetivities 
affeet  many  programs  of  reeord  and  exist  at  an  enterprise  management  level  that  is 
evolving  and  eurrently  eo-existing  with  traditional  Title  10  resouree  sponsor 
responsibilities  to  “man,  train  and  equip”  the  operational  forees.  Resource  sponsors  have 
difficulty  justifying  investments  that  are  not  unambiguously  related  to  Programs  of 
Record  or  organizational  operations.  The  establishment  of  the  portfolio  management 
construct  is  part  of  the  remedy  for  this  problem  but,  the  concept  is  young  and  the 
processes  and  authorities  of  the  portfolio  leads  are  still  being  tested  and  defined  (CJCSb, 
2007).  Even  within  the  portfolio  construct  there  are  necessary  fiscal  boundaries  that  must 
be  defined.  COIs  are  inherently  collaborative  in  nature  and  resource  sponsors  are 
reluctant  to  commit  resources  to  activities  that  are  beyond  their  formal  control,  oversight 
and  accountability. 
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Finally,  the  migration  toward  COIs  appears  to  have  been  aetively  or 
unintentionally  hindered  by  data  administration  professionals,  data  modelers,  reealeitrant 
government  program  managers  and  industry  vendors  who  may  have  vested  interests  in 
maintaining  the  status  quo.  When  asked  why,  one  senior  data  strategist  quipped, 
“...beeause  there  is  profit  in  ehaos.”  Data  sharing  in  a  net-eentrie  environment  violates 
the  basie  business  tenet  of  “design  onee,  sell  many”  and  supplants  it  with  the  less 
profitable  model;  “build  onee,  use  many  ...  for  free.”  The  teehnologies  being  exploited  in 
a  net-eentrie  environment  are  requiring  eompanies,  developers  and  their  government 
sponsors  to  learn  and  implement  quiekly  (Dartmouth,  2007). 

D,  10  STEPS 

Unfortunately,  the  definition  of  COIs  eontributes  to  some  of  the  eonfusion.  Based 
on  the  explieit  and  implied  roles  and  responsibilities  in  the  Direetive,  there  is  a 
substantial  engineering  and  development  element  to  COL  In  most  COIs  this  is 
aeeommodated  in  a  sub-group  to  the  COI  that  reports  to  the  COI  leadership.  Integrated 
produet  development  teams  are  responsible  for  establishing  metadata  strueture,  defining 
eommunity  ontologisms,  establishing  shared  spaee  and  eataloging  data  (DoDb,  p.5). 
These  are  not  traditional  user  roles  and  ean  stymie  COI  establishment  early  in  the 
organizational  lifeeyele. 

In  an  effort  to  soeialize  and  explain  the  tenets  of  COI  to  a  broad  Navy  audienee, 
my  eolleague  Paul  Shaw  and  I  developed  a  brief  entitled  the  “First  10  Steps”  for  COI 
development.  The  introduetory  slide  to  that  brief  is  shown  in  Figure  4.2.  The  brief  was 
used  in  2006  and  2007  to  help  bound  the  COI  issue,  edueate  ourselves  and  our  eolleagues 
and  assist  others  who  were  attempting  to  implement  or  eomply  with  DoD  poliey.  At  the 
time  Paul  was  one  of  the  advisors  to  the  Maritime  Domain  Awareness  and  many  of  the 
lessons  learned  eame  from  his  partieipation  in  the  Data  Management  Working  Group 
established  to  support  that  Northern  Command  (NORTHCOM)  led  effort. 
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step  1 :  Define  COIs  Mission  and  Objectives 

Step  2:  Identify  COI’s  Champion,  Members  and  Stakehoiders 

Step  3:  Develop  COI  CONOP 

Step  4:  Identify  Reiated  COI’s  and  Products 

Step  5:  Establish  COI  Governance  Structure  and  Process 

Step  6:  Establish  Methodoiogy  for  Coiiaboration  and 
Sociaiization 


Identify  COI  Information  Sharing  Challenges 
Prioritize  Information  Sharing  Capabiiities 
Develop  Initial  COI  Products 


Step? 

Step  8 
Step  9 

Step  10:  Establish  Initiai  COI  Pilots 


Figure  4-2:  COI  First  10  Steps 


After  the  COI  is  established  and  the  produets  are  developed  and  validated  through 
piloting,  the  COI  is  faced  with  influencing  the  acquisition  community  to  integrate  the 
products  in  programs  of  record  that  will  sustain  capability  and  deliver  it  to  end  users. 


E.  CROSS  COMMUNITY  SHARING 


Although  there  was  a  collective  desire  to  establish  communities  of  interest  and 
mature  them  to  support  development  teams  and  end  users,  few  of  the  initial  COIs  that 
were  identified  and  registered  in  2004  remain  active.  As  of  June  2008  only  30  of  170 
COIs  have  created  and  registered  artifacts  in  the  DoD  Metadata  Registry  (MDR,  2008). 
Of  the  COIs  that  did  begin  to  meet  and  develop  artifacts,  various  new  challenges  arose  as 
the  individual  data  domains  attempted  to  support  a  user  base  that  was  simultaneously 
executing  multiple  missions.  The  dearth  of  personnel  that  had  experience  with  web 
services,  data  modeling  and  the  concepts  of  enterprise-level  problem  solving  ensured  a 
chronic  understaffing  of  these  efforts.  This  resulted  in  a  small  set  of  government 
engineers.  Federally  Funded  Research  and  Development  Corporations  (FFRDC)  and 
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defense  contractor  support  personnel  who  worked  multiple  COI  efforts,  shared  lessons 
learned  and  carried  attitudes,  perspectives  and  data  management  working  groups. 

Each  COI  had  a  different  learning  curve  and  entered  into  the  COI  development 
process  at  different  levels  of  maturity.  They  also  had  different  levels  of  political 
commitment  and  high  variability  in  their  funding  availability.  In  an  effort  to  adjudicate 
issues  between  COIs  and  more  formally  share  lessons  learned,  OSD  Nil  established  the 
CIO  Forum  in  2006.  One  of  the  first  issues  taken  up  by  the  COI  Forum  was  the  problem 
relating  to  cross-COI  interoperability.  Although  the  COIs  were  implementing  the  same 
policies  and  using  the  same  standards,  cross-COI  harmonization  was  not  occurring. 
There  was  a  potential  therefore  of  creating  new  stovepipes  of  net-centric  data  which 
when  implemented,  would  fall  short  of  the  conditions  needed  for  net-centric  operations 
to  occur.  Interoperability  would  require  layers  of  mediation  or  mediation  services 
between  COIs  to  achieve  the  desired  level  of  machine-to-  machine  interoperability. 


Figure  4.3  depicts  one  of  the  principle  processes  that  the  COI  Forum  generated 
and  endorsed.  The  workflow  is  a  simple  graphical  representation  of  the  steps  and 
relationships  that  a  community  would  go  through  to  define  itself,  the  vocabulary  it 
desired  to  share  and  the  mechanism  to  make  it  discoverable  to  others  in  DoD.  What  the 
workflow  is  unable  to  depict  is  the  tremendous  amount  of  time  and  effort  required  to 
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form  a  community,  and  the  degree  of  leadership,  follower-ship,  administrative  overhead, 
and  eolleetive  goodwill  required  to  eome  to  agreement  on  the  lexieons  and  their 
relationships. 

At  the  same  time  DoD  was  striving  to  inerease  the  slope  of  its  net-eentrie  learning 
eurve,  other  departments  in  the  federal  government  were  under  similar  pressures  to 
improve  interageney  interoperability  and  reduee  overall  investment  in  IT.  This  had  been 
a  thrust  from  Congress  and  the  Offiee  of  Management  and  Budget  sinee  the  late  1990s, 
but  the  events  of  September  11,  2001  and  the  subsequent  911  Commission  Report 
findings  ehanged  that  desire  for  interoperability  to  a  national  mandate  and  strategy 
(National  Seeurity  Couneil,  2007). 

The  Federal  approaeh  to  data  sharing  is  ineorporated  in  the  Federal  Enterprise 
Architeeture  (FEA)  ereated  by  the  Offiee  of  Management  and  Budget.  The  Arehitecture 
is  eomprised  of  a  eolleetion  of  interrelated  referenee  models  designed  to  faeilitate  eross- 
ageney  analysis  to  help  identify  duplieative  investments,  gaps,  and  opportunities  for 
eollaboration  within  and  aeross  Eederal  Ageneies.  The  eomponents  of  the  EEA  are 
shown  in  Eigure  4.4. 


Performance  Reference  Model  (PRM) 

Business  Roforonce  Model  (BRM) 

Service  Component  Reference  Model  (SRM) 
Data  Reference  Model  (DRM) 

Technical  Reference  Model  (TRM) 


si 

2 1 


Eigure  4-4;  Eederal  Enterprise  Architecture  (Source  0MB) 


F.  DATA  REFERENCE  MODEL 

IEEE  610. 12-1990  defines  a  model  as  “an  approximation  representation,  or 
idealization  of  aspeets  of  behavior,  operating  or  other  characteristics  of  real  world 
proeesses,  coneepts  or  systems”  (Maier  and  Rechtin,  p.l45).  The  Data  Reference  Model 
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(DRM)  reflects  the  same  technical  and  organizational  considerations  for  data  sharing  as 
those  reflected  in  DoD  directives.  0MB  intends  for  the  DRM  to  be  used  by  federal  data 
and  system  architects  to  describe  information  in  such  a  way  that  it  can  be  easily  located 
and  used  across  multiple  federal  agencies. 

Models  can  be  helpful  in  defining  abstract  concepts  related  to  network  centric 
theory  and  describing  enterprise  behaviors.  The  data  reference  model  provides  high  level, 
implementation  neutral  guidelines  for  enterprise  data  management.  It  is  composed  of 
defining  vocabularies,  placing  data  in  context  and  sharing  data.  The  document  describes 
in  detail  the  reasoning  behind  each  of  the  three  main  concepts  and  how  they  relate  to  each 
other.  The  DRM  describes  how  COIs  should  define  their  vocabularies  as  hierarchical 
taxonomies  to  facilitate  classification  of  data  which  then  allow  alignment  based  on  the 
context  of  the  Mission  Area  or  Line  of  Business  (LOB).  Alignment  within  DoD  refers  to 
mapping  the  lexicons  to  the  Mission  Areas  and  Joint  Capability  Areas  as  displayed  in 
Figure  4.1. 

G.  RESULTS  OF  COLLABORATION 

COI  collaboration  eventually  spawned  a  hypothesis  that  cross-domain 
interoperability  could  be  built  into  the  CIO  data  artifacts  if  the  most  commonly  used 
terms  could  be  defined  and  used  as  a  starting  point  for  data  taxonomy  development.  It 
was  an  attractive  argument  that  promised  to  improve  consistency  of  implementation  and 
facilitate  the  development  of  a  data  interoperability  design  pattern.  The  concept  became 
known  as  the  Universal  Core. 

In  an  effort  to  capitalize  on  the  political,  technical  and  cultural  momentum  that 
had  developed  the  DoD  Chief  Information  Officers,  the  Intelligence  Community 
chartered  a  short  duration  study  in  January  2007  to  evaluate  the  feasibility  of  defining  and 
creating  the  Universal  Core  as  a  reusable  information  exchange  standard  and 
implementation  profile.  The  next  chapter  describes  the  evolution  of  Universal  Core  in 
the  context  of  a  federal  Community  of  Interest  case  study. 
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V.  CASE  STUDY:  UNIVERSAL  CORE 


uni*ver*sal:  Adjective 

-  Embracing  a  major  part  or  the  greatest  portion. 

-  Adapted  or  adjustable  to  meet  varied  requirements. 

Merriam-Webster  Online  Dietionary  (2008) 


A.  ORGANIZATION 

In  January  2007,  the  Offiee  of  the  DoD  CIO  and  the  Intelligenee  Community 
CIO,  in  their  roles  as  co-leads  for  the  Senior  Enterprise  Services  Govemanee  Group 
(SESGG),  established  the  Common  Core  Task  Eoree  that  was  ehartered  to  evaluate  the 
eoneepts  of  data  sharing  defined  in  Eederal  poliey  and  to  evaluate  the  various  efforts  that 
were  ongoing  in  the  Eederal  government  at  the  time.  This  resulted  in  an  unpublished 
Eebruary  2007  report  entitled  “Criteria  for  Universality  and  Utility  of  Information 
Struetures”  (CCTE,  2007).  The  report  noted  that  the  “traditional  mindset  of  metieulously 
doeumenting  information  exehange  requirements  elearly  does  not  deliver  the  type  of 
business  proeess  agility”  required  for  interageney  partnering  and  data  sharing.  The  report 
went  on  to  theorize: 

One  approaeh  to  mitigating  this  problem  is  to  adopt  existing  agreements 
on  semanties  and  syntax  for  eoneepts  that  are  universal  (or  at  least  broadly 
eommon),  thus  forming  a  “Universal  Core”  of  implementable  objeets  that 
will  be  used  in  information  systems  wherever  praetieable  (CCTE,  p.  8) 

In  April  2007  as  a  follow-up  to  the  report,  the  SESGG  established  the  Universal 
Core  Working  Group.  The  eharter  was  broadly  deseribed  to  provide  the  working  group 
the  opportunity  to  evaluate  best  praetiees  in  government  and  industry.  The  primary  tasks 
of  the  working  group  were  to  define  those  voeabulary  terms  that  eould  be  eonsidered 
fundamental  to  all  information  exehanges,  gain  eonsensus  on  the  terms  by  the  various 
departments  and  ageneies  within  DoD  and  the  IC,  and  implement  the  voeabulary  as  an 
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information  exchange  specification.  The  Office  of  the  DoD  CIO  tasked  Navy  to  lead  the 
effort.  I  was  assigned  the  working  group  lead  for  DoD  and  the  co-lead  was  designated 
from  the  Office  of  the  Director  of  National  Intelligence,  Mr.  Jim  Feagans.  This  effort  was 
to  be  completed  by  the  end  of  fiscal  year  2007.  Typical  for  this  type  of  IPT,  no  funding 
was  provided,  no  labor  was  dedicated  to  the  effort,  and  the  co-leads  were  not  relieved  of 
their  existing  responsibilities.  Despite  these  challenges,  the  allure  of  establishing  a  small, 
lightweight  information  exchange  specification  that  would  serve  as  the  foundation  for 
COI  and  cross  departmental  interoperability  was  enough  to  maintain  senior  level  interest 
and  technical  level  participation. 

B,  MISSION  AND  OBJECTIVES 

The  Common  Core  Task  Force  Report  served  as  the  foundation  for  the  initial 
working  group  objectives.  The  paper  provided  a  broad  conceptual  definition  of  Universal 
Core  and  some  design  tenets  that  served  as  the  underpinnings  of  the  concept.  The 
Common  Core  Task  Force  defined  Universal  Core  as  “the  set  of  concepts  that  require  no 
domain-specific  expertise  for  understanding,  i.e.  a  set  of  things  that  anyone  can 
understand”  (CCTF,  p.4).  They  went  on  to  define  a  Universal  Object  as  “an 
implementable  specification  of  syntax  and  semantics”  of  the  universal  terms  defined 
above.  The  tenets  were  modified  to  express  more  concrete  themes  that  could  be  used  to 
define  and  scope  working  group  deliverables: 

•  The  benefits  of  a  Universal  Core  framework  will  occur  when  everyone  can 
agree  on  and  implement  the  fundamentals. 

•  The  specification  must  be  documented  and  technically  implementable  so 
that  developers  can  code  against  it  and  program  managers  can  put  it  on 
contract. 

•  Extensibility  is  considered  an  essential  quality.  However,  it  does  not 
mean  that  the  core  itself  is  changed  by  any  extensions. 

•  Implementation  must  be  cost  effective. 
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c. 


INITIAL  CHALLENGES 


As  requirements,  these  definitions  and  tenets  eonstituted  very  broad  vision 
statements.  Although  UCore  was  to  be  defined  as  a  teehnieal  speeifieation,  the  first 
ehallenges  were  philosophieal  in  nature.  In  order  for  the  Core  to  be  eonsidered  truly 
universal  the  eoneepts  and  terms  in  the  eore  had  to  be  eontext  free.  That  is,  they  had  to  be 
defined  and  represented  in  a  way  that  every  data  domain  and  Community  of  Interest 
eould  use  them.  Sinee  the  working  group  had  a  broad  eharter,  it  was  able  to  evaluate  all 
previous  data  sharing  initiatives  and  to  deduee  what  was  eommon  among  them.  Analysis 
by  MITRE  Corporation  determined  that  almost  80  pereent  of  all  taetieal  message  traffie 
(i.e..  Link  16)  eontained  the  primary  eoneepts  of  “who,”  “what,”  “where”  and  “when” 
(MITRE,  2006).  These  fundamental  eoneepts  were  first  introdueed  to  western 
philosophy  by  Aristotle,  are  the  foundational  eoneepts  for  joumalistie  writing  and  serve 
as  the  basis  for  intelligenee  eommunity  reporting.  Other  data  sharing  initiatives  sueh  as 
Cursor  on  Target  and  the  Strike  Community  of  Interest  had  started  to  define  these  basie 
eoneepts  as  part  of  their  taxonomies  although  they  did  so  in  the  eontext  of  their  speeifie 
mission  areas. 

Ultimately,  time  and  resouree  eonstraints  foreed  the  working  group  to  reduee  the 
initial  seope  of  the  projeet  to  defining  only  two  abstraet  eoneepts  of  “where”  and  “when.” 
These  are  the  terms  that  eould  be  most  easily  defined  in  terms  of  “loeation”  and  “time.” 
Loeation  and  time  are  also  formally  represented  in  Geographie  Markup  Language  and 
ISO  8601  respeetively.  Additionally  the  group  believed  that  the  politieal  payoff  resulting 
from  the  two  primary  stakeholders  agreeing  to  anything  outweighed  any  desires  by  the 
group  to  aeeept  the  risk  of  trying  to  inelude  all  four  terms. 

The  next  major  ehallenge  that  was  addressed  by  the  working  group  dealt  with  the 
syntaetieal  representation  of  the  voeabulary  terms.  Prior  to  the  definitions  being  agreed 
upon,  data  modelers  and  designers  were  reluetant  to  ehoose  a  single  physieal  model  for 
fear  of  being  boxed  in  for  future  development.  The  major  point  of  eontention  between 
the  various  experts  was  whether  to  speeify  XML  in  a  physieal  instantiation  ealled  an 
XML  Sehema  Deseription  (XSD)  or  leave  the  physieal  modeling  up  to  the 
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implementation  teams.  Voeiferous  debate  oeeurred  between  PhDs  who  were  veterans  of 
the  Artifieially  Intelligenee  community  and  continued  to  conduct  advanced  research  on 
the  emerging  semantic  web  and  other  WEB  3.0  concepts.  In  the  end  the  co-leads 
refocused  the  debate  on  what  could  be  feasibly  implemented  during  fiscal  year  2007  and 
what  the  overall  cost  to  the  government  would  be  for  implementation.  XML  was  chosen 
as  the  logical  representation  for  the  concepts  with  the  physical  schema  being  represented 
in  XSDs. 

Organizing  for  effective  operations  was  the  next  obstacle.  The  co-leads  were 
geographically  displaced  by  3000  miles  in  San  Diego  and  Washington  DC  respectively. 
The  volunteer  technical  workforce  was  distributed  throughout  the  country.  This 
necessitated  design  meetings  being  conducted  primarily  through  teleconferencing.  Initial 
meetings  were  large  and  many  of  the  participants  were  attending  in  a  defensive  role  to 
protect  their  organizational  equities  rather  than  contribute  meaningfully  to  the  effort. 
These  interested  onlookers  distracted  the  government,  technical  and  subject  matter 
experts  who  were  actually  engaged  in  meaningful  work.  In  order  to  improve  efficiency, 
the  co-leads  created  sub-groups  that  were  limited  to  those  who,  through  peer  review,  had 
demonstrated  a  clear  understanding  of  XML,  data  modeling  techniques,  web  services  and 
an  understanding  of  the  political  goals  of  the  project.  In  time  the  draft  products  from 
these  subgroups  were  vetted  to  the  larger  community  for  review  and  official  comment. 

The  technical  task  of  defining  a  few  common  terms  in  XML,  documenting  the 
meaning  (i.e.,  semantics)  and  formatting  (i.e.,  syntax)  are  not  complex  and  could  be  done 
in  a  reasonable  time  by  two  or  three  developers.  However,  since  the  goal  of  Universal 
Core  was  interagency  adoption,  the  SESGG  mandated  that  the  design  team  meetings  be 
unrestricted  and  widely  advertised.  Although  face-to-face  meetings  were  difficult  to 
organize,  three  of  these  were  conducted  and  proved  invaluable  to  maintaining  the  project 
on  schedule.  Teleconferencing  is  an  excellent,  cost  effective  tool  but  it  is  not  substitute 
for  the  human  interaction  that  builds  loyalty,  trust  and  team  spirit. 

The  co-leads  hosted  the  first  meeting  at  MITRE  facilities  in  Mclean  Virginia  the 
third  week  in  July  2007.  Lorty  five  individuals  representing  over  20  organizations  within 

DoD  and  the  IC  attended.  Although  well  organized  with  timelines  and  subgroup 
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deliverables,  the  event  was  a  frustrating  failure  for  the  eo-leads  as  well  as  the  partieipants. 
It  resulted  in  little  more  than  an  introduetion  to  the  Universal  Core  and  a  venue  to  air 
grievanees  from  previous  data  sharing  initiatives.  The  deeision  was  made  to  end  the 
meeting  at  noon  on  the  seeond  day  when  it  appeared  that  meaningful  progress  was 
unattainable. 

In  an  attempt  to  render  some  form  of  progress  from  an  otherwise  stalled  initiative, 
the  eo-leads  invited  a  handful  of  colleagues  to  a  small  conference  room  to  strategize  the 
way  ahead.  The  individuals  were  picked  for  their  ability  to  objectively  advise  the 
government,  their  reputation  within  the  data  community,  and  their  experience  on  other 
Communities  of  Interest.  The  meeting  lasted  four  hours  and  by  the  end  of  it,  a 
reasonable  plan  of  action  and  milestones  (POAM)  had  been  drafted,  vocabulary  terms 
and  some  attributes  had  been  defined,  data  standards  had  been  prioritized,  challenges 
identified,  and  tasks  assigned.  That  meeting  was  the  galvanizing  event  in  the  entire 
UCore  effort.  To  the  co-leads  it  served  as  an  epiphany  that  the  Universal  Core  initiative, 
and  data  sharing  in  general,  is  primarily  a  human  endeavor  supported  by  a  technical 
component. 

The  UCore  team  worked  through  August  via  weekly  developer  teleconferences 
and  almost  daily  conversations  by  the  government  co-leads.  The  data  engineers  reported 
out  in  the  third  week  in  August  that  they  would  be  able  to  define  and  build  the 
implementation  profiles  for  the  concepts  of  “when”  and  “where”  that  would  be 
conformant  to  policy,  consistent  with  international  data  standards  and  valid  in  the  context 
of  XML  parsing  tools.  The  government  was  in  a  position  to  be  able  to  deliver  a  product  to 
the  oversight  body  that  could  be  called  the  Universal  Core  that  would  conform  to  the 
tenets  of  the  original  SESGG  tasking. 

One  final  face-to-face  meeting  was  called  in  early  September  to  review  the 
artifacts,  assumptions  and  political  considerations  of  the  effort.  The  month  of 
September  2007  was  devoted  to  creating  a  Development  and  Implementation  Guide 
(DIG)  for  Universal  Core  Version  1.0.  The  DIG  contained  and  background  on  the  UCore 
effort,  guidance  on  how  to  build  and  extend  UCore  artifacts  in  order  to  tailor  them  to 

specific  mission  needs  and  examples  XSDs  to  guide  implementation.  The  government 
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leads  reviewed  the  artifaets  and  agreed  that  the  effort  had  produeed  a  valuable,  but 
limited,  information  exehange  speoifieation.  They  made  the  deeision  to  present  UCore 
to  the  SESGG  reeommending  UCore  not  be  released  for  implementation  but  be  used  as 
an  example  of  government,  industry,  aeademia  partnering  and  the  ability  to  eollaborate 
on  teehnieal  standards.  They  also  reeommended  the  immediate  initiation  of  UCore  V2.0 
to  be  developed  and  implemented  in  Fiseal  Year  2008.  The  update  slide  in  Figure  5.2 
below  was  presented  as  part  of  a  status  brief  to  DoD  CIO  representatives  on  27 
September  and  provides  insight  into  the  status  of  the  effort  and  government  eoncems  and 
goals  for  the  initiative. 


Universal  Core  V1.0  Status 


I*  Status 

-  Final  Coordination:  DISA  (Jaci)  and  Kevin  K 
-  Pilot  Efforts  need  coordination 

-  Navy  players  reorganizing  to  support  the  continuing  effort 
-  Buy  In:  Excellent  from  DNI,  WG  leads  and  Service  N6s 
•  Technologists  are  reluctantly  supportive 
•  Everyone  protecting  their  equities:  that  is  OK...  for  now 


•  Lessons  Learned 

-  Agreement  can  be  reached  if  there  are  methods  for  reclama  and 
redress 

-  The  right  government  players  need  to  stay  involved 

-  FFRDC  has  been  a  key  partner  that  must  stay  involved  in  a  tech 
advisory  role 

-  We  have  momentum  even  though  most  players  are  still  defensive 

-  Without  more  discipline  (project  management),  the  coalition  will  start  to 
fray  during  the  V1.0  pilots  and  V2.0  development 

-  Level  of  Effort 

•  It  took  more  than  we  thought 

•  Voluntary  collaboration  is  not  enough 


Figure  5-1;  UCore  VI. 0  Status.  27  Sep  2007  Brief  to  OASD  Nil 

D,  RESULTS  AND  REACTION 

Universal  Core  VI. 0  was  released  for  DoD  and  Intelligence  Community  review 
the  week  of  04  October  2007.  It  was  hailed  immediately  by  DoD  and  IC  leadership  as  a 
success.  Politically,  the  teams  had  come  together,  overcome  cultural  and  organizational 
barriers,  and  produce  a  joint  technical  product.  The  UCore  initiative  proved  that  there 
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was  latent  capability  previously  funded  by  the  DoD  and  IC  that  could  be  leveraged  to 
support  mission  accomplishment.  It  proved  that  the  human  agreement  was  a  necessary 
prerequisite  to  interagency  interoperability  and  that,  given  the  necessary  political  top 
cover  and  guidance,  the  technical  teams  from  across  the  services,  agencies  and  the 
Intelligence  Community  could  work  together  to  accomplish  something  meaningful. 

From  a  technical  perspective  UCore  was  considered  successful  as  a  proof  of 
concept.  Although  UCore  Vl.O  showed  that  the  concepts  of  “when”  and  “where”  could 
be  defined  in  a  universally  understandable  way  and  these  two  terms  would  be  insufficient 
for  meaningful  information  exchanges  to  support  decision  making  or  mission 
accomplishment.  Finally  UCore  Vl.O  showed  that  the  XML  community  of  practice  is 
now  mature  enough  to  be  able  to  implement  machine-to-machine  interoperability  without 
any  special  tools  or  training.  UCore  Vl.O  was  submitted  to  the  SESGG  on  October  04 
2007  as  the  FY07  Working  Group  deliverable.  The  Working  Group  recommendation 
was  to  not  mandate  UCore  Vl.O  because  of  the  perceived  limitations  and  to  immediately 
initiated  UCore  V2.0  development.  However,  several  members  of  the  user  community 
did  not  agree  that  Vl.O  was  too  small  to  be  valuable  and  commenced  immediate  testing 
and  implementation. 

E,  UCORE  Vl.O  PILOTS 

Despite  the  working  group  recommendations  the  user  community  was  poised  to 
evaluate,  test  and  implement  Universal  Core  upon  its  release.  Only  a  few  actual 
implementations  occurred  but  they  were  significant.  It  showed  the  Universal  Core 
concept  had  some  value  to  some  operational  end-users.  The  most  illustrious  example  of 
end-user  initiative  is  reflected  in  a  Strategic  Command  (STRATCOM)  project  called 
SKI  WEB. 

As  described  by  General  Bob  Kehler,  Deputy  Director  of  STRATCOM,  SKIWEB 
stands  for  Strategic  Knowledge  Integration: 

...we  use  SKIWEB  as  a  knowledge  management  network.  We  use  it  in 
the  headquarters  as  a  never-ending  Ops  Intel  meeting,  and  in  fact  it  is  the 
key  tool  the  senior  leadership  uses  to  stay  abreast  of  events  unfolding 
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throughout  the  command  and  the  world  in  real  time. . .  all  prioritized  by  the 
commander’s  critical  information  requirements  (Kehler,  p.l). 

Upon  release  of  UCore  the  SKIWEB  development  team  commenced  refactoring 
the  “where”  and  “when”  concepts  within  their  existing  schema  to  UCore  Vl.O.  The 
team  had  been  working  with  various  members  of  the,  data  community  including  Strike 
COI,  Blue  Force  Tracking  COI  and  Cursor  on  Target  (COT).  UCore  Vl.O  had  borrowed 
from  those  initiatives,  simplified  and  improved  upon  these  two  primary  concepts.  By 
November  2007,  SKIWEB  had  imbedded  UCore  into  their  product  and  were  testing  it  on 
their  development  LAN.  The  SKIWEB  team  initiated  contact  with  the  Ministries  of 
Defense  of  United  Kingdom  and  Australia  and  shared  the  concepts  and  schema  with 
them.  Over  a  period  of  a  few  short  months,  the  SKIWEB  team  mandated  that  data 
producers  create  UCore  compliant  messages,  was  able  to  get  National  Security  Agency 
Certification  and  Accreditation,  and  conducted  successful  experimentation  with  the 
Allies. 

The  value  attributed  to  UCore  Vl.O  was  that  it  forced  data  producers  to  conform 
to  a  standardized  way  of  depicting  time  and  location  so  that  SKIWEB  sources  could  be 
combined  on  a  map  without  mediation.  As  of  March  2008,  SKIWEB  had  12000  users, 
including  the  Chairman  of  the  Joint  Chiefs  of  Staff.  This  is  an  example  of  the  flexibility 
of  XML  based  technologies,  the  agility  of  Web  2.0  design  teams,  and  the 
transformational  power  of  motivated  teams.  The  SKIWEB  /  UCore  pilot  is  a  shining 
example  of  the  type  of  operationally  driven  capabilities  promised  by  net-centric 
operations  literature. 

F.  UCORE  V2,0 

Buoyed  by  the  political  success  of  the  UCore  Vl.O  delivery  in  early  October, 
DoD  CIO  and  the  IC  CIO  decided  to  invite  the  Department  of  Justice  (DOJ)  and  the 
Department  of  Homeland  Security  (DHS)  to  contribute  to  the  evolution  of  a  common 
information  specification  that  could  be  used  across  the  four  departments.  DoD  and  the  IC 
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had  long  standing  and  often  mutually  supportive  relationships,  but  the  addition  of  DHS 
and  DOJ  to  the  UCore  V2.0  design  and  development  team  ereated  signifieant  politieal, 
teehnical  and  cultural  challenges. 

The  most  immediate  and  glaring  of  these  challenges  was  that  DOJ  had  already 
created  and  mandated  a  data  model  and  framework  called  the  National  Information 
Exchange  Model  (NIEM)  and  had  a  concept  of  the  universal  cores  and  common  cores 
embedded  in  that  product  offering.  In  addition,  political  tension  existed  between  the 
developer  communities  because  DoD  and  IC  had  evaluated  NIEM  and  found  it  a  valuable 
product,  but  one  that  was  tailored  to  the  Eaw  Enforcement  community  and  not  generally 
applicable  to  the  DoD  /  IC  mission  portfolios. 

The  first  meeting  of  the  UCore  V2.0  development  team  occurred  on  17  October 
2007  less  than  two  weeks  after  the  release  of  Vl.O.  I  was  asked  to  continue  to  lead  the 
effort  and  the  Chief  Technology  Officer  from  the  Department  of  Justice,  Jeremy  Warren, 
was  assigned  as  the  UCore  V2.0  Development  Working  Group  co-lead.  My  tasking  from 
the  Office  of  the  Assistant  Secretary  of  Defense  was  stated  simply;  “create  something  all 
the  departments  can  agree  on!”  The  government  leads  had  confidence  that  a  technical 
solution  could  be  developed  based  on  the  lessons  learned  from  UCore  Vl.O;  however  we 
were  very  aware  that  the  political  acceptance  would  be  the  driver  behind  UCore  V2.0 
adoption. 

As  fate  would  have  it,  the  same  week  the  UCore  V2.0  kickoff  meeting  occurred, 
two  important  national  policy  documents  were  released,  the  President’s  “National 
Strategy  for  Information  Sharing,”  and  the  “Cooperative  Maritime  Strategy  for  the  2U* 
Century”  co-signed  by  the  Navy,  Marine  Corps  and  Coast  Guard.  Both  these  documents 
reflected  the  concepts  of  interagency  information  sharing  in  the  context  of  missions  that 
were  common  to  all  four  departments.  This  provided  a  great  opportunity  for  the 
government  leads  to  jettison  old  baggage  associated  with  previous  efforts  and  focus  on 
implementing  these  policies  from  a  fresh  perspective. 

The  challenges  the  design  team  faced  for  the  development  of  UCore  V2.0  were 
the  same  as  during  the  UCore  Vl.O  remained.  There  was  no  dedicated  funding,  no 
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dedicated  labor  pool,  and  the  schedule  stretched  to  the  end  of  the  fiscal  year.  Since  all  the 
players  had  other  responsibilities  in  their  primary  jobs,  it  was  decided  to  design  and 
develop  as  rapidly  as  possible  before  the  UCore  concept  lost  momentum.  During  the 
initial  meeting,  ground  rules  were  set  for  participation,  reporting  responsibilities  were 
established,  success  criteria  were  defined,  and  project  termination  conditions  were 
articulated. 

The  DOJ  and  DHS  representatives  brought  to  the  table  a  high  level  of  political 
capital,  experience  with  a  mandated  data  model,  and  recent  success  with  large  scale  data 
integration  at  the  user  community  level.  Most  importantly  however,  the  DOJ  /  DHS 
government  team  brought  recent  Web  2.0  technologies  experience  from  commercial 
sector.  In  addition  to  the  CTO,  Justice  also  tasked  their  Chief  Data  Architect,  Boris  Shur, 
to  support  the  effort.  Boris,  and  the  DHS  lead,  Anthony  Hoang,  had  been  members  of  the 
design  and  implementation  team  for  Global  Synchronization  1 ,  and  Boris  was  a  data  pool 
manager  for  the  Global  Data  Synchronization  Network  (GSDN).  GDSN  standardized 
vocabularies  for  the  retail  industry  to  facilitate  international  commerce.  Their  website 
boasts  that  product  sales  of  over  3  trillion  dollars  were  executed  over  GDSN  in  2007 
(GDSN,  2008). 

The  DOJ  lead,  Mr.  Warren,  was  also  the  National  Information  Exchange  Model 
(NIEM)  Program  Manager  who  had  accrued  significant  political  capital  by  incorporating 
NIEM  into  the  Counter  Terrorism  Information  Sharing  Standard  (CTISS).  The  CTISS 
specification  was  a  product  of  the  Program  Manager  for  the  Information  Sharing 
Environment,  Ambassador  Ted  McNamara,  Special  Assistant  to  the  President.  DoD  and 
the  IC  brought  political  capital,  recent  collaborative  success  on  UCore  Vl.O  and  various 
degrees  of  success  from  a  number  of  data  sharing  initiatives.  All  four  departments  also 
brought  the  organizational  baggage  inherent  in  every  large  federal  agency  bureaucracy. 

After  several  preliminary  rounds  of  sparing,  the  government  leadership  and  the 
volunteer  support  staff  began  to  achieve  traction  on  the  Plan  of  Action  and  Milestones.  It 
was  agreed  that  regardless  of  the  technical  outcome.  Universal  Core  V2.0  could  be 
considered  a  success  since  it  represented  a  level  of  interagency  technical  collaboration 

that  had  not  been  attempted  before.  With  the  fear  of  failure  removed,  the  team  spent  six 
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weeks  drafting  a  Vision  and  Scoping  Document  which  describes  the  goals,  schedules, 
definition  of  various  levels  of  interoperability  and  articulated  compliance  profiles. 


Phase  1: 

Phase  II; 

Evaluate  Technical 
Alternatives 

Phase  III: 

Phase  IV: 

Scoping 

UCORE  V2.0 

Test  &  Evaluation 

17  OCT- 11  DEC 


12  DEC- 15  FEB 


16  FEB -15  APR 


16  APR -30  MAY 


Phase  V: 

Pilot 

Implementation 

Phase  VI; 

Phase  VII: 

Review  Lessons 

Community 

Learned  &  Finalize 
UCORE  V2.0 

Review  &  Approval 
UCORE  V2.0 

01JUN-31JUL  01  AUG -31  AUG  01  SEP -30  SEP 


Figure  5-2;  UCore  V2.0  Plan  of  Action  and  Milestones 


G.  A  CAPABILITIES  DOCUMENT 

The  most  important  aspect  of  the  Vision  and  Scope  Document  was  that  it 
permitted  the  individuals  working  on  UCore  V2.0  to  congeal  as  a  team  and  served  as  a  de 
facto  capabilities  document  for  the  effort.  The  document  was  drafted  through  continuous 
peer  review  in  a  period  of  less  than  six  weeks  and  contained  the  assumptions,  objectives, 
success  criteria  and  schedule  that  served  as  the  blueprint  against  which  progress  on  the 
effort  was  measured. 

The  Vision  and  Scope  Document  describes  a  conceptual  construct  that  is 
instantiated  as  an  Information  Exchange  Specification  and  Implementation  Profile.  It  is 
comprised  of  five  parts  (I)  vocabulary  and  set  of  consistent  data  definitions  for  most 
commonly  exchanged  concepts  (“who,”  “what,”  “where,”  and  “when”),  (2)  the  XML 
representation  of  those  concepts,  (3)  extension  rules  to  allow  tailoring  to  specific  mission 
areas,  (4)  security  markings  to  permit  controlled  access  and  electronic  tear  lines,  (5)  and  a 
messaging  framework  to  package  and  unpackage  content  consistently.  The  Vision  and 
Scope  Document  was  approved  by  the  UCore  ESC  in  early  January. 
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The  design  phase  of  the  effort  began  immediately  thereafter  with  an  abbreviated 
Analysis  of  Alternatives  that  evaluated  the  approaches  to  the  “what,  when,  where,  who” 
concepts  from  across  the  Federal  Enterprise.  Data  models  are  architectural  products  that 
developers  need  to  consistently  implement  information  exchanges.  In  1975  the  American 
National  Standards  Institute  (ANSI)  described  three  levels  of  data  schema;  conceptual, 
logical  and  physical.  Conceptual  models  describe  the  semantics  of  a  domain  and  bound 
the  scope  of  the  model  (Wikipedia,  2008). 

Unfortunately  the  raw  materials  for  the  UCore  preliminary  analysis  resulted  in  a 
compilation  of  130  pages  of  Conceptual  Data  Models  from  various  efforts.  This  proved 
impossible  to  review  during  the  weekly  teleconferences.  Since  all  the  models  were 
essentially  redundant  and  UCore  quality  metrics  were  based  on  simplicity,  the  Working 
Group  leads  tasked  the  design  team  to  decompose  the  existing  models  and  create  one  of 
no  more  than  one  page,  on  a  Power  Point  slide.  This  was  accomplished  in  a  week.  The 
development  of  this  artifact.  Figure  5.3  below,  was  the  tipping  point  for  UCore  V2.0 
design  and  permitted  rapid  progress  and  meaningful  discussion  by  a  distributed  technical 
team  of  40  engineers  and  subject  matter  experts  who  routinely  dialed  into  the  weekly 
meetings. 


Figure  5-3:  UCore  V2.0  Conceptual  Data  Model 
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H,  DESIGN  /  DEVELOPMENT  PHASES 


In  order  to  remain  on  track  the  design  team  resorted  to  extreme  programming 
methods.  After  the  analysis  period  ended  on  15  February,  an  eight  week  design  and 
development  period  commenced.  The  team  initiated  one  week  spirals  involving  daily 
peer  review,  modification  and  updating.  The  end  result  was  logical  data  models  and 
physical  instantiations  of  the  concepts  in  XML  Schema  Descriptions  (XSD). 
Additionally  during  this  time  the  draft  implementation  guidance  was  developed.  Peer 
review  occurred  in  real  time  via  teleconference  and  government  review  and  approval 
occurred  in  near-real-time  via  email  at  the  end  of  each  business  day.  On  April  16th,  the 
government  leads  terminated  the  design  phase  and  initiated  two  weeks  of  government 
review  and  documentation  refinement.  The  UCore  technical  specification  was  released 
for  interagency  testing  on  16  April  which  concluded  31  July  2008.  Over  20  evaluation 
teams  from  DoD,  DOJ,  IC  and  DHS,  all  four  military  Services,  DISA,  two  COCOMs,  as 
well  as  the  City  of  Colorado  Springs  are  participated.  A  composite  evaluation  report  is 
scheduled  to  be  produced  and  released  for  community  review  on  15  August.  Figure  5.4 
below  depicts  the  Developers  Guide  plus  an  example  of  the  instance  documents. 


0©  s  • 


UCore  V2.0  Vision 
And  Scoping 
Document 


UCore  V2.0 
Description  and 
Implementation  Guide 


jANOA.xml 


XML  Document 
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XML  Document 
XML  Document 


eventOfUncertainTime.xml 
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Figure  5-4:  UCore  V2.0  Artifacts 
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I.  GOVERNANCE 

The  original  governance  structure  of  the  Senior  Enterprise  Services  Governance 
Group  (SESGG)  did  not  have  DOJ  and  DHS  representatives.  Because  there  is  no 
technical  organization  with  authorities  to  span  the  Eederal  Government,  a  special 
Executive  Steering  Committee  (ESC)  was  established  to  exercise  UCore  governance. 
The  voting  members  are  Deputy  CIOs,  from  DoD,  DOJ,  DHS  and  the  IC  with  advisory 
members  from  0MB  (Chief  Architect)  and  the  Program  Manager  for  Information  Sharing 
Environment  (PM  ISE).  This  senior  level  participation  made  the  UCore  chain  of 
command  very  short  and  decision  making  very  efficient.  Although  not  a  formal 
acquisition  effort,  the  ESC  served  in  the  capacity  of  a  Milestone  Decision  Authority  for 
the  effort. 

J,  POLITICAL  CAPITAL  /  TECHNICAL  ADOPTION 

The  Universal  Core  effort  has  gained  substantial  political  momentum  over  the 
past  nine  months.  Momentum  was  fed  by  interagency  design  teams  who  either 
implemented  or  experimented  with  UCore  VI. 0  and  by  the  growing  number  of  UCore 
V2.0  Alpha  testers  who  are  reporting  positive  results  from  their  preliminary  findings. 
The  government  leads  initially  became  concerned  about  the  level  of  visibility  and  “pre¬ 
adoption”  occurring  across  the  communities.  As  noted  in  the  following  paragraphs,  new 
policies,  major  programs  of  records,  and  a  broad  stakeholder  base  are  all  reflecting 
UCore  as  an  emerging  requirement  for  information  sharing.  After  several  weeks  of 
attempting  to  evaluate  risk,  one  government  lead  described  the  conditions  as  a  “perfect 
storm,”  implying  that  political,  technical  and  cultural  conditions  are  converging  during 
this  effort  (Peterson,  2000).  Because  it  was  no  longer  under  their  control,  the  team 
decided  to  acknowledge  the  risk  and  ride  it  out. 

The  UCore  Executive  Steering  Committee  has  socialized  UCore  at  the  highest 
levels  in  the  Eederal  Government.  This  has  resulted  UCore  being  an  agenda  items,  topic 
of  discussion  or  project  of  interest  across  a  broad  spectrum  of  stakeholders  as  noted  in  the 
bullets  below: 
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•  On  17  July,  the  Office  of  Assistant  Secretary  of  Defense  tasked  the  UCore 
Working  Group  leads  to  brief  the  Information  Sharing  Council,  lead  by  the 
Special  Assistant  to  the  President  and  comprised  of  the  Chief  Information 
Officers  (CIOs)  of  all  Cabinet  level  departments.  That  briefing  is  scheduled  to 
occur  in  September. 

•  On  15  July,  the  UCore  government  leads  and  the  chief  engineer,  briefed  the 
Interoperability  Defense  Science  Board  who  will  be  incorporating  the  UCore 
lessons  learned  into  their  report  to  SECDEF  Gates. 

•  UCore  is  being  written  into  the  rewrite  of  CJCS  6212. IE,  “Interoperability  and 
Supportability  of  Information  Technology  and  National  Security  Systems  “as  part 
of  the  Net  Ready  Key  Performance  Parameter. 

•  UCore  was  briefed  by  the  to  ASD  Nil,  John  Grimes  and  the  CIOs  of  all  military 
services,  JCS  J6,  the  IC  CIO  and  the  DISA  commander  on  7  July.  They  have 
requested  an  update  in  September  that  includes  the  findings  from  the  Alpha  pilot 
teams. 

•  On  17  April  2008,  the  DoD  CIO  and  IC  CIO  released  a  joint  memorandum 
endorsing  the  UCore  concept  and  encouraging  its  continued  development. 

•  DHS  and  DOJ  are  currently  drafting  a  joint  UCore  endorsement  memo  to  be 
signed  by  the  CIOs  of  the  four  principle  departments  that  will  encourage  the  use 
of  UCore. 

•  The  March  2008  Business  Transformation  Report  to  Congress  cites  on  page  261, 
UCore  as  a  "Key  Program  and  Accomplishment"  for  Data  and  Services 
Implementation. 

•  PM  ISE  (Program  Manager  for  Information  Sharing  Environment)  incorporated 
UCore  into  the  Counter  Terrorism  Information  Sharing  (CTISS)  Specification  and 
reflected  the  harmonization  of  UCore  with  the  NIEM  data  model  in  the 
Information  Sharing  Environment  Framework  in  March  2008. 
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K,  SUMMARY 


UCore  can  represent  the  human  and  teehnical  starting  point  for  improved 
interageney  interoperability.  It  is  based  on  the  premise  that  a  basie  level  of 
interoperability  ean  be  built  into  the  Federal  Enterprise  by  defining,  standardizing  and 
sharing  a  few  fundamental  information  elements.  This  small,  simple  to  implement 
voeabulary  serves  both  as  the  teehnical  cornerstone  to  build  richer,  more  complex 
information  exchanges  and  it  ean  be  used  as  an  interfaee  for  legacy  infrastructure 
integration.  Stakeholders,  teehnieians  and  managers  can  evaluate  UCore  in  the  context  of 
their  speeilic  missions  and  lines  of  business.  This  reduees  their  individual  risk  but  also 
ereates  a  sense  of  ownership  and  partieipation  in  the  proeess.  Initial  piloting  efforts  are 
reinforeing  this  assertion  as  will  be  deseribed  it  the  concluding  chapter. 

As  a  case  study,  UCore  refleets  the  phases  and  ehallenges  and  potential  suceess 
that  apply  to  all  Communities  of  Interest.  The  final  ehapter  will  highlight  some 
preliminary  results  from  the  UCore  Alpha  testing  teams  are  reporting  and  it  will  artieulate 
how  this  thesis  contributes  to  the  literature  on  information  sharing. 
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VI.  THESIS  CONTRIBUTION 


The  best  way  to  aehieve  seeurity  is  to  prevent  war. 

Robert  Gates,  SECDEF 
National  Defense  Strategy,  June  2008 


A,  OVERVIEW 

The  new  Maritime  Strategy  released  in  October  2007,  articulates  Navy  tasking  in 
the  context  of  global  security  and  highlights  the  roles  maritime  forces  play  in  exercising 
political,  economic  and  military  forms  of  national  power.  The  strategy  stresses  that  the 
Navy  must  be  prepared  to  win  when  forced  to  fight.  However  it  places  equal  emphasis 
on  enhancing  deterrence  capability,  building  national  prestige  and  wielding  economic 
might  to  stabilize  an  inherently  volatile  world.  This  same  theme  is  reinforced  in  the 
National  Defense  Strategy  released  by  the  Secretary  of  Defense  in  June  2008.  In  it 
Secretary  Gates  states: 

We  as  a  nation  must  strengthen  not  only  our  military  capabilities,  but  also 
reinvigorate  other  important  elements  of  national  power,  and  develop  the 
capability  to  integrate,  tailor  and  apply  these  tools  as  needed. 

This  thesis  has  reviewed  the  tenets  of  Joint  Vision  2020  and  the  technical 
concepts  of  DoD  Transformation  in  the  context  of  the  new  “Cooperative  Maritime 
Strategy  for  the  2E‘  Century.”  It  hypothesizes  that  Decision  Superiority  requires  a 
renewed  emphasis  on  the  fundamentals  of  decision  making.  The  thesis  asserts  that  in  the 
emerging  communications  environment,  information  overload  may  be  managed  through 
greater  discipline,  e.g..  Ignorance  Management  as  a  risk  reduction  concept  to  focus 
decision  makers  and  supporting  IT  professionals  on  getting  the  “right  information,  to  the 
right  people,  at  the  right  time.”  This  thesis  introduces  the  concept  of  Information 
Readiness  Eevels  to  help  operational  forces  more  objectively  gage  the  ability  of  the 
information  architecture  to  support  decision  making  in  the  context  of  specific  missions.  It 
also  asserts  that  technical  convergence  has  occurred  and  that  the  promise  of  network¬ 
centric  operations  can  become  a  closer  reality  as  organizational  and  cultural  evolution 

63 


continues.  The  thesis  eontains  examples  of  organizational  evolution  with  a  survey  of 
portfolio  management  and  Communities  of  Interest  policies.  Finally,  the  thesis  eoneludes 
with  a  case  study  of  the  Universal  Core,  an  interageney  information  sharing  initiative  that 
is  an  example  of  enterprise  behavior  and  politieal,  teehnieal  and  cultural  progress  in  this 
area. 

B,  FINDINGS 

It  appears  that  the  tenets  of  earlier  Navy  and  DoD  net-eentrie  doetrine  remain 
valid.  Information  and  Deeision  Superiority  are  foree  multipliers  but  the  new  Maritime 
Strategy  entails  viewing  network-eentrie  strategy  from  a  different  perspeetive.  It  plaees 
renewed  emphasis  on  aeeelerating  cultural  change  to  use  Network  Centrie  Operations 
teehnologies  to  advance  readiness  in  all  mission  areas.  The  need  for  viewing  information 
requirements  through  a  new  lens  is  highlighted  in  “A  Day  in  the  Life  of  the  Navy”.  The 
Chief  of  Naval  Information  press  release  states  that  on  14  May  2008  in  addition  to 
eombat  in  the  CENTCOM  Theater  of  Operations,  naval  forees  were  engaged  in 
“Operation  Caring  Response,”  “Operation  Inspired  Union,”  “Operation  Continuing 
Promise”  and  “Paeifie  Partnership  08,”  a  four  month  humanitarian  deployment  by  the 
hospital  ship  USNS  Mercy. 

These  new  missions  are  being  exeeuted  and  superimposed  upon  an  information 
sharing  infrastrueture  tailored  to  support  command  and  control,  kill  chains  and  battle 
damage  assessment.  A  fair  assessment  is  that  the  information  architeeture  is  groaning 
under  the  strain.  U.S.  Navy  sailor  inventiveness,  and  some  progress  in  adopting  a  more 
agile  Global  Information  Grid  are  showing  promise,  but  are  not  enough.  The  Enterprise 
Information  Environment  is  stretehing,  being  redefined,  and  driving  new  data, 
information  and  deeision  support  requirements.  This  thesis  eontributes  to  an 
understanding  of  how  the  IT,  aequisition  and  data  sharing  eommunities  are  attempting  to 
address  these  issues  through  an  enterprise  approaeh  to  data  strategy  implementation. 

The  eoncepts  of  right  information,  to  the  right  person  at  the  right  time,  are  just  as 
applieable  to  effeetive  eoordination  in  this  new  environment  as  they  are  in  the  timeless 
realm  of  warfighting.  However,  the  Navy’s  emerging  missions  redefine  somewhat  the 
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concepts  of  “right,”  including  calling  for  a  reevaluation  of  information  types,  information 
partners  and  information  qualities  sueh  as  latency,  trust  and  completeness.  The 
requirements  derived  from  new  missions,  and  those  that  drive  acquisition  and  data 
strategies,  must  reemphasize  decision  making  as  a  process,  rather  than  a  solo  event. 
Decision  processes  can  be  agile  but  they  cannot  be  haphazard  if  deeision  superiority  is  to 
be  achieved.  Workflows,  mission  threads,  and  task  sequences  ean  support  more 
consistent  decision  making,  and  when  used  in  a  SOA,  can  be  made  visible  to  the  network 
and  invoked  as  reusable  services.  When  data  qualities  are  defined  in  the  context  of  the 
decision  cycle,  these  serviees  can  be  orehestrated  and  used  to  groom  the  information 
arehiteeture  to  colleet  value-adding  data,  filter  out  noise  and  align  the  information 
produets  more  closely  with  the  business  or  mission  needs. 

Portfolio  Management  and  Communities  of  Interest  can  represent  politieal  and 
organizational  progress  toward  a  net-centric  environment.  These  eonstruets  deal  direetly 
with  the  ehallenges  of  DoD  funetioning  as  an  enterprise,  not  only  from  a  joint  operations 
perspeetive,  but  in  the  eontext  of  Planning,  Programming,  Budgeting,  Execution  and 
Acquisition.  Communities  of  Interest  are  essentially  Integrated  Product  Teams  that  are 
keyed  to  a  data  domain  or  information  sharing  problem.  They  provide  support  that  DoD 
and  Federal  polieies  are  being  read,  understood  and  executed.  COIs  are  a  manifestation 
of  enterprise  behavior.  They  are  ereating  a  vanguard  of  professionals  who  are  gaining 
experience  in  the  teehnieal  management  challenges  of  large  seale  collaboration  required 
for  implementing  a  Services  oriented  architectural  paradigm. 

C.  CASE  STUDY  RESULTS 

The  Universal  Core  was  conceived  as  a  way  to  improve  interoperability  between 
emerging  Communities  of  Interest.  It  is  founded  on  the  premise  that  a  basic  level  of 
interoperability  can  be  built  into  the  Federal  Enterprise  by  defining,  standardizing  and 
sharing  a  few  fundamental  information  elements.  In  a  little  over  a  year,  it  has  evolved 
from  coneept  paper  into  a  multi-agency  Federal,  State  and  Foeal  data-sharing  initiative 
that  has  the  potential  to  improve  decision  making,  increase  publie  confidenee,  and 
preserve  taxpayer  money.  As  a  case  study  it  reflects  the  real  opportunities  and  limitations 
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of  data  sharing  in  a  net-centric  environment  and  is  representative  of  the  challenges  that 
are  faced  by  all  Communities  of  Interest,  agencies  and  departments. 

The  Universal  Core,  as  a  venue  for  interagency  cooperation,  is  breaking  down 
organizational  barriers  that  have  stymied  meaningful  technical  exchanges  between 
government  executives  and  government  engineers.  Universal  Core  is  being  managed  as 
an  executive  level  Integrated  Product  Team  (IPT)  across  four  departments;  IC,  DoD,  DOJ 
and  DHS.  The  UCore  team  has  analyzed  new  commercial  standards,  design  patterns, 
architectural  constructs  and  best  practices  from  across  the  Federal  Government  to  create  a 
lightweight  implementation  profile  that  significantly  reduces  the  technical  and  fiscal 
barriers  to  entry  faced  by  organizations  migrating  to  a  net-centric  environment.  It  also 
helps  eliminate  excuses  for  non-compliance  to  DoD  and  Federal  policy. 

UCore  has  the  potential  of  saving  the  government  significant  development, 
integration,  and  sustainment  costs.  By  providing  a  starting  point  for  data  model 
development  and  an  interface  for  integration,  dollars  that  would  have  previously  been 
allocated  to  recreating  these  baseline  elements  can  now  be  spent  on  improving  the  quality 
and  precision  of  data  being  exchanged.  The  Universal  Core  also  supports  the  concept  of 
short  term,  highly  specialized  information  exchanges  for  emerging  missions.  Institutional 
or  ad  hoc  Communities  of  Interest  can  reuse  the  Universal  Core  and  extend  the  baseline 
precepts  to  tailor  their  information  architecture  in  an  operationally  feasible  timeframe  and 
at  an  acceptable  cost.  The  Universal  Core  principle  design  criteria  are  simplicity  and 
ease  of  use.  Testing  of  initial  versions  of  the  specification  indicate  the  concept  is  valid 
with  pilot  teams  experiencing  development  times  measured  in  terms  of  days  and 
integration  times  in  terms  of  weeks. 

D,  CASE  STUDY  IMPLICATIONS 

On  23  July  2008,  the  UCore  Working  Group  held  its  final  meeting  of  the  piloting 
phase.  As  usual  this  was  done  via  teleconference.  Everyone  reported  their  status  and  the 
leads  provided  an  update  on  the  increasing  level  of  visibility  and  political  momentum  the 
initiative  was  receiving.  No  discussion  about  Contract  Line  Item  Numbers,  cost 
overruns,  or  requests  for  additional  schedule  occurred.  No  contracts  had  been  negotiated. 
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This  group  of  professionals  came  together  one  last  time,  bound  only  by  their  desire  to 
contribute  to  the  effort.  As  the  lead,  I  had  to  encourage  and  remind  the  teams  to  finish 
their  reports,  thank  them  for  their  contributions  and  wish  them  well  in  their  future 
endeavors.  It  was  a  strange  feeling  to  have  managed  a  team  that,  with  few  exceptions,  I 
recognized  only  through  the  sound  of  their  voices  or  their  email  addresses. 

In  a  practical  sense,  we  had  achieved  interagency  interoperability  on  the  first  day, 
when  we  had  decided  to  consider  ourselves  a  community  of  practice.  The  technical 
artifacts  we  created  and  tested  merely  allowed  us  to  refine  and  sustain  those  roles.  The 
team  had  arrived  at  consensus,  captured  and  documented  their  agreements  in  the  form  of 
data  assets  and  now  desired  to  share  their  work  with  others.  This  has  inspired  the  first 
UCore  heuristic:  All  technical  exchanges  are  predicated  upon  prior  human  agreement. 

E.  POLITICAL  LESSONS  LEARNED 

In  a  less  poetic  vein,  the  implications  and  lessons  learned  from  the  case  study  can 
be  grouped  into  three  broad  categories;  Political,  Technical  and  Cultural.  Politically,  the 
case  study  reinforces  Step  Two  from  the  Community  of  Interest  training  slide  introduced 
in  Chapter  4,  “Identify  Champions,  Members  and  Stakeholders.”  The  primary  lesson  is 
that  Step  2  is  not  a  milestone  but  a  continuous  process.  Data  strategy  implementation, 
when  viewed  as  a  data  modeling  exercise,  can  appear  to  be  an  esoteric  art,  practiced  by 
intelligent,  highly  opinionated  individuals  from  diverse  technical  and  non-technical 
backgrounds.  Champions  and  stakeholders  can  be  end-users  who  neither  understand  nor 
care  about  the  technical  details.  Stakeholder  management  is  difficult,  necessary  and  time 
consuming.  Therefore,  to  maintain  momentum,  courting  and  gaining  new  champions  can 
be  the  most  powerful  prime  mover. 

UCore  was  blessed  with  an  energetic  Senior  Executive  Service  leader,  Mr.  Mike 
Krieger,  who  provided  continuous  support,  encouragement  and  top  cover  to  the 
government  development  team.  Mr.  Krieger  brought  the  CIOs  of  the  IC,  DOJ  and  DHS 
to  the  table  with  the  DoD  CIO  and  worked  tirelessly  to  keep  them  there.  He  briefed 
increasingly  senior  players  about  the  potential  of  UCore  and  the  progress  the 
development  team  was  making.  These  included  the  most  senior  uniformed  officers  in 
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DoD,  political  appointees  and  even  a  Special  Assistant  to  the  President.  The  UCore  team 
also  sought  out  organizational  champions  and  used  the  fact  that  STRATCOM  had 
incorporated  UCore  Vl.O  into  a  tool  being  used  by  the  Chairman  of  the  Joint  Chiefs  of 
Staff  as  a  low  voltage  prod  to  stimulate  friendly  competition  between  the  organizations. 
This  continuously  growing  number  of  champions  inspired  the  technieians,  permitted  the 
government  leads  to  ereate  a  “failure  is  not  an  option”  culture,  led  to  a  great  deal  of  peer 
review  and  ultimately  resulted  in  a  better  product.  These  lessons  confirmed  the  seeond 
UCore  heuristie:  “If  you  have  no  ehampions,  you  may  be  playing  the  wrong  game.” 

An  additional  lesson  learned  from  the  use  case  is  that  in  implementing  the  data 
strategy  across  the  federal  enterprise;  there  are  no  natural  barriers.  The  bureaucracies 
that  we  have  established  to  manage  people  and  tasks  are  reinforeed  by  our  respective 
requirements,  aequisition,  and  budgeting  systems.  These  bureaucracies,  however,  do  not 
represent  the  edges  of  the  data  domains  for  those  organizations.  Bureaucracies  provide 
necessary  stability  and  predictability  but  are  frequent  impediments  to  innovation. 
Enterprise  behavior  requires  individuals  to  temporarily  shed  their  organizational 
affiliations  when  they  form  data  sharing  eommunities  and  ereate  a  team  culture.  As  an 
example  of  this,  the  government  leads  would  rebuke  each  other  for  using  the  term  “you” 
during  meetings.  Philosophieally  speaking,  the  collective  eapability  of  “we”  was  finite 
while  the  resources  of  “you”  were  pereeived  to  be  infinite.  This  business  rule 
contributed  to  self-correcting  behavior  that  resulted  in  more  praetieal  goals,  proeesses  and 
feasible  deliverables.  Heuristie  number  three  is:  In  order  to  aehieve  interagency 
interoperability  you  must  bend  the  bureaucracy  to  achieve  the  common  good. 

F.  TECHNICAL  LESSONS  LEARNED 

There  were  teehnieal  lessons  learned  from  the  UCore  case  study.  The  piloting 
teams  are  testing  up  to  50  function  points  associated  with  data  formatting,  extensibility 
and  exehange.  These  lessons  learned  will  be  doeumented  by  the  UCore  Development 
Working  Group  and  will  be  validated  by  a  panel  of  senior  government  and  industry 
personnel  in  mid- August.  A  slide  from  the  UCore  Exeeutive  brief  lists  the  top  15  pilots. 
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Risk  Reduction  Piiots  IJ  niver«»i 

“90  days,  no  funding,  GO!”  «re 


Pilot  Name 

Mission  Functional  Area 

Lead  Org 

SKIWEB 

Event  Notification  (Multinational  SA) 

STRATCOM 

SEAHAWK 

Maritime  Domain  Awareness  (MIEM) 

DOJ  /  MDA 

SENSORWEB 

Sensor  Integration  (Empire  Challenge) 

DIA 

ISPAN 

Nuclear  Planning  System  Integration  (SOA) 

STRATCOM 

EDXL 

Emergency  Management  Integration 

DHS 

Fed  Force  Tracker 

GPS  To  UCore  For  Domestic  Cross-agency 

Emergency  Vehicle  Tracking 

ATFP 

Tactical  Edge  (MC) 

Binary  VMF  to  UCore  XML 

Marine  Corps 

NECC 

C2  Program  of  Record 

DISA 

SAU/COT 

Strike  /  Situational  Awareness  Update 

AF 

Strike  COI 

COI  Extensions 

STRATCOM  / 
Army 

Air  Ops  COI 

COI  Extensions 

AF/JFCOM 

ONR  LIE 

Open  Track  Management  Service 

Navy 

NIEM  -  UCore 

Common  Framework  Interoperability 

DOJ/  DOD 

AMPS 

Automated  Metadata  Tagging  -  UCore  Orchestration 

AF 

In  addition,  8  other  organizations  are  reviewing  and  providing  feedback  during  this  evaluation 


Note:  Acronyms  defined  in  backup  12 


Figure  6-1 :  UCore  V2.0  Risk  Reduction  Pilots  (Source:  UCore  Executive  Brief) 


A  few  macro  findings  are  already  clear.  Networking  technologies,  content 
sharing,  syndication  practices,  maturation  of  technical  standards,  and  the  growth  of  a 
web-services  community  of  practice  have  largely  converged.  The  UCore  initiative 
provides  support  that  a  ten  year  investment  in  net-centric  concepts  and  eGovernment  has 
created  an  environment  conducive  for  advanced  capability.  UCore  evolved  from  many 
other  data  sharing  initiatives  including  Strike  COI,  Cursor  on  Target  (CoT),  and  NIEM. 
The  team  was  influenced  by  government  leadership  fresh  from  industry.  It  also  tapped 
into  a  pool  of  existing  talent  funded  for  related  efforts  but  dispersed  on  various  projects. 

Technical  progress  would  have  been  more  difficult  if  latent  capability  did  not 
already  exist.  UCore  development  teams  were  merely  provided  a  draft  XME  based 
specification  and  were  asked  to  test  and  use  the  specification  within  the  context  of  a 
mission  area  that  they  defined.  They  were  offered  no  training  or  funding  and  were  asked 
to  work  collaboratively  to  prove  or  disprove  value  of  the  specification  in  a  period  of  90 
days.  Twenty  three  teams  volunteered  because  they  were  already  working  on  data 
sharing  efforts  using  XML  based  data  exchange  patterns,  and  they  desired  to  orchestrate 
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or  enhance  their  project  with  UCore.  While  none  of  the  teams  had  any  experience  with 
the  UCore  V2.0  implementation  profile,  all  of  the  team  had  experience  with  XML  and  the 
web-based  services  that  permit  XML  content  to  be  transferred  over  IP  networks. 
Although  there  were  costs  associated  with  UCore,  the  teams  bore  them  under  their 
respective  organization’s  execution  year  dollars,  effectively  distributing  the  fiscal  burden 
of  developing  and  testing  Universal  Core  V2.0  across  four  Federal  departments.  The 
previous  decade  of  investment  allowed  UCore  to  leverage  the  infrastructure  and  be 
developed  and  tested  with  no  direct  funding.  In  a  very  real  sense,  UCore  constitutes  the 
Return  on  Investment  envisioned  by  net-centric  theorists  and  stated  in  data  sharing 
strategies.  An  example  of  this  ROI  is  reflected  in  the  orchestration  of  AMPS  and  UCore 
in  what  one  developer  enthusiastically  described  as  “pure  capability.” 

G.  AMPS  /  UCORE 

In  late  May  2008  the  UCore  leads  provided  a  routine  status  update  to  the  Service 
level  Senior  Enterprise  Service  Governance  Group.  The  UCore  update  was  followed  by 
an  Air  Force  representative  who  briefed  the  Automated  Metadata  Population  Service 
(AMPS).  Air  Force  had  worked  jointly  with  the  other  uniformed  services  on  two 
versions  of  AMPS  for  approximately  two  years.  Both  concepts  were  endorsed  by  the 
SESGG.  That  afternoon  the  UCore  team  wrote  the  Air  Force  lead,  Mr.  Josh  Powers, 
requesting  additional  information  and  expressing  a  desire  for  a  technical  exchange  to 
occur.  Mr.  Powers  responded  and  a  technical  exchange  meeting  (TEM)  was  scheduled 
for  early  May.  The  TEM  was  conducted  via  teleconference  between  three  sites;  San 
Diego,  Colorado  Springs  and  Washington  DC.  Having  read  the  Power  Point  presentation 
concerning  AMPS,  UCore  team  wanted  to  know  if  their  product  could  be  used  as  part  of 
AMPS  to  automatically  tag  unstructured  data  with  the  semantics  from  the  UCore 
specification.  Twenty  minutes  into  the  TEM,  Mr.  Powers  indicated  that  if  UCore  could 
be  place  in  an  ontology  format  known  as  OWL,  UCore  could  then  serve  as  an  annotator, 
or  metadata  template,  for  the  unstructured  data.  At  25  minutes  into  the  TEM,  the  UCore 
Chief  Engineer,  Brian  Freeman,  had  converted  the  XML  based  schema  into  an  OWL 
schema  with  a  common  commercial  software  tool.  The  technical  exchange  ended  after 
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30  minutes  with  Mr.  Powers  indieating  he  had  everything  he  needed.  He  told  the 
government  leads  that  he  would  report  back  after  he  tested  the  newly  integrated 
components.  At  2  PM  that  day,  Mr.  Powers  sent  a  sample  of  the  metadata  tags  that 
resulted  from  running  600  unstructured  files  through  AMPS  and  indexing  these  files  with 
UCore  semantics.  The  total  processing  time  was  20  minutes.  In  systems  engineering 
terms  this  new  “system”  had  evolved  from  concept  exploration  to  design,  development 
and  proceeded  through  initial  operational  testing  in  less  than  one  day.  Total  labor 
expended  by  both  teams  (e.g.,  three  individuals)  was  approximately  two  hours.  There 
was  no  software  development  and,  with  the  exception  of  the  conversion  from  XML  to 
OWL,  there  was  nothing  that  could  be  considered  a  modification  of  the  two  efforts. 

The  ability  to  automatically  metadata  tag  structured  and  unstructured  data  is  a 
watershed  event.  It  contributes  to  solving  one  of  the  most  challenging  aspects  of  the  net- 
centric  data  strategy;  making  data  visible.  This  means  that  large  volumes  of  useful  data 
that  the  federal  government  collects,  but  which  may  not  be  visible  enterprise-wide  are 
now  discoverable  through  common  search  engines.  As  importantly,  this  can  be  done  in 
the  context  of  the  approved  terms  and  definitions  used  by  the  federal  government.  Also 
because  UCore  is  extensible  and  the  AMPS  annotator  engine  can  accommodate  these 
extensions,  the  possibility  exists  that  data  can  be  precisely  tagged  to  specific  mission 
areas  and  lines  of  business.  This  could  reduce  data  overload,  allow  precision  data 
indexing  that  could  lead  to  significant  improvements  in  providing  the  right  information  to 
the  right  person  at  the  right  time.  The  full  implications  of  this  effort  are  still  under  review 
and  will  be  included  in  the  final  UCore  evaluation  report. 

The  ability  to  design  a  “service”  that  can  ingest  another  design  team’s  product  to 
create  a  tailored,  new  capability  is  not  special.  In  fact  it  is  the  state  of  the  practice.  Being 
Web  2.0  practitioners,  Mr.  Powers  and  Mr.  Freeman  did  not  even  consider  this  an  issue 
worthy  of  mention.  The  government  leads  however,  were  impressed.  This  concept  of 
service  orchestration,  or  choreography,  is  fundamental  to  Service  Oriented  Architectural 
paradigms  and  is  in  common  use  in  industry.  This  rather  long  example  resulted  in 
heuristic  number  5:  With  respect  to  the  service  oriented  paradigm,  the  future  is  now. 
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H.  CULTURAL  LESSONS  LEARNED 


From  a  management  perspeetive,  probably  the  most  interesting  lessons  learned 
from  the  ease  study  relate  to  eultural  ehange  indicators,  e.g.,  four  Federal  Departments 
started  sharing  their  perspectives  and  requirements  on  interagency  interoperability. 
Cultural  change  was  also  stimulated  when  diverse  teams  were  allowed  the  freedom  to 
develop  rapidly  and  collaboratively  in  real-time.  An  organizational  design  feature  was 
enhanced  towards  self-managing  teams,  resulting  in  a  more  productive  and  collaborative 
approach.  While  some  were  use  to  this  type  of  extreme  programming  and  rapid 
prototyping,  others  indicated  they  had  never  done  it  in  a  government  project.  Developers 
were  not  used  to  being  allowed  to  execute  a  “try-fail-try  again”  design  process  under 
continuous  government  monitoring  but  without  interference  or  the  threat  of  negative 
repercussions.  Government  managers  had  modified  or  expanded  their  roles  from 
customer  to  participant,  as  the  developers  were  not  under  direct  contract  to  the 
government  leads. 

Developers  and  modelers  also  had  to  reorient  a  traditional  bureaucratic  approach 
by  learning  to  terminate  development,  often  before  they  were  comfortable  with  the 
product.  The  government  leads  had  high  thresholds  for  individual  risk  and  decided  to 
reduce  it  by  sharing  “work  in  process”  with  other  development  teams.  This  ultimately 
resulted  in  a  massive  peer  review  effort  that  reflected  the  influences  of  recent  government 
experience  in  organizations  and  efforts  like  the  Global  Data  Synchronization  Network. 
To  get  an  idea  of  the  degree  of  peer  review,  the  experienced  government  leads  estimated 
the  project  would  take  a  full-time  team  of  five  developers  six  weeks  to  complete.  The 
initiative  had  no  full  time  developers  and  no  simple  way  to  estimate  the  available  labor 
hours.  In  the  end,  an  estimated  80  engineers  helped  during  the  design  and  development 
phases.  These  two  phases  combined  took  14  weeks.  Because  the  peer  review  process 
brought  in  so  many  players,  the  government  leads  not  only  had  a 
product  at  the  end  of  the  phase,  but  they  had  investments  from  a  large  number  of 
organizations  and  a  vested  interest  in  success  that  facilitated  the  initiation  and  execution 
of  the  evaluation  phase. 
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The  government  team  also  had  to  eonseiously  ehange  their  perspective  during  the 
requirements  development  and  the  analysis  of  alternatives  phases  to  ensure  they  were  not 
focusing  too  exclusively  on  gaps  and  problems.  The  focus  was  on  improving  what 
already  had  proven  successful  rather  than  fixing  what  was  wrong.  This  permitted  the 
team  to  more  accurately  define  what  was  feasible  within  the  confines  of  the  time  and 
resource  limitations.  This  focus  on  extending  success  rather  than  overcoming  problems 
allowed  the  teams  to  make  fast,  visible  progress  and  helped  attract  new  champions, 
stakeholders  and  peer  reviewers. 

Another  cultural  indicator  during  the  progress  of  the  case  was  observing  the 
emergence  of  a  generational  power  shift.  As  the  team  lead  during  the  briefing  to  the 
Defense  Science  Board  on  15  July  2008,  I  stressed  this  point  to  the  retired  Service 
Secretaries,  Flag  and  General  Officers  of  the  Board.  My  colleagues  at  the  table 
constituted  the  UCore  government  leadership  for  the  effort  and  one  non-government 
engineer  serving  as  Chief  Engineer.  All  the  government  leads  were  GS-15  equivalents. 
Three  of  the  six-team  leads  were  under  32  years  old.  The  Chief  Engineer  was  27.  The 
other  three  government  leads  were  over  50  years  old.  Only  one  of  the  government  leads 
over  50  had  any  direct  experience  with  Web  2.0  development.  He  was,  however, 
acknowledged  as  brilliant  and  the  “spiritual”  leader  of  the  technical  team.  This  meant 
that  although  everyone  was  of  equal  “rank”,  the  younger  generation  of  players  led  and 
facilitated  the  project.  This  is  mentioned  as  a  positive  cultural  indicator,  in  that  the 
acknowledgment  of  the  technological  competence  of  the  younger  participants  facilitated 
and  encouraged  a  successful  outcome.  Due  to  the  speed  at  which  technology  is  moving, 
an  engineer  under  40  is  likely  to  be  at  the  height  of  their  technical  capabilities,  and 
capitalizing  on  this  expertise  connotes  an  evolving  organizational  maturity.  Engineering 
expertise  may  or  may  not  translate  into  equivocal  managerial  prowess,  e.g.,  managing  in 
a  political  arena. 

The  current  popularity  of  the  ElCore  concept  will  soon  be  tempered  by  the 
enormity  of  the  tasks  remaining.  There  is  a  great  deal  of  effort,  compromise  and  cost 
associated  with  achieving  measurably  improved  government  interoperability.  However 
the  current  UCore  buzz  is  representative  of  the  kind  of  confidence  that  initial  net-centric 
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successes  ean  generate  and  build  upon.  The  group  of  industry  and  government  leaders 
that  eondueted  the  Web  2.0  exereise  at  Dartmouth  is  representative  of  this  phenomenon: 

. . .  [PJraetieal  leadership  by  senior  exeeutives  will  be  ealled  for  to  navigate 
through  and  derive  business  value  from  this  transition  to  a  more  “open” 
form  of  engagement  with  both  external  eonstitueneies  and  internal  talent. 

While  partieipants  had  varying  views  on  the  urgeney  of  the 
transformation,  a  palpable  spirit  of  optimism  and  exeitement  pervaded  the 
group  about  the  opportunities  Web  2.0  presents  to  forward  thinking 
eompanies  in  the  eoming  years  (Dartmouth,  2007). 

This  has  inspired  the  final  ease  study  heuristie:  In  a  Web  2.0  world,  respeet  the  grey¬ 
beard  but  start  heeding  the  adviee  of  no-beards. 

I.  AREAS  FOR  FUTURE  RESEARCH 

There  are  a  number  of  topies  within  the  net-eentrie  data  sharing  area  that  are 
worthy  of  additional  study.  Following  the  outeome  of  the  Universal  Core  Consolidated 
Evaluation  Report  for  any  teehnieal,  politieal  or  eultural  implieations  of  the  Federal 
government’s  move  to  eommon  data  standards  would  be  interesting.  A  review  of  the 
Portfolio  Management  eonstruet  would  be  valuable,  possibly  using  the  Warfare  Mission 
Area  and  8410.01  as  a  starting  point  to  deseribe  the  ehallenges  and  sueeesses  of  that  new 
govemanee  approaeh  to  information  teehnology.  A  study  that  eompares  and  eontrasts 
sueeessful  and  unsueeessful  attempts  at  standing  up  Communities  of  Interest  might  prove 
useful.  It  eould  inelude  the  well  established  ones  like  Strike  COI  and  emerging,  or  ad  hoe 
COIs  sueh  as  are  being  developed  for  the  Afriea  Partnership  Stations  in  the  newly  formed 
Afriea  Command.  Evaluating  and  potentially  maturing  the  eoneept  of  Information 
Readiness  Eevels  would  be  a  reasonable  researeh  topie  espeeially  for  those  newly 
arriving  operational  offieers  from  the  Fleet. 
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